“The difference between good and bad architecture is the time you spend on it.”
– David Chipperfield
There is a specific kind of architect that worries me.
Not the junior one learning the ropes. Not the experienced one who double checks the consequences.
I mean the architect who is absolutely convinced they are right, and talks incessantly to prove it.
I was in the war room at 2 AM, staring to the aftermath of what was supposed to be our next evolutionary leap.
We pushed the final piece of our cloud migration at midnight.
By 12:07 AM, 60% of our customers couldn’t log in.
By 12:15 AM, the rollback plan failed because the servers it was meant to restore to didn’t even exist anymore.
Despite the thorough migration plan, the old system was gone … extinct in a single night, and our “evolved” architecture had nowhere to run.
We didn’t anticipate the blind spots, and the post-mortem read like a crime scene report where we were both the victim and the suspect.
That’s when I realised Darwin’s theory applied to software too: Software behaves like living organisms.
A few years ago, I took a week off. First vacation in months. On day two, I got six Slack messages, three “urgent” calls, and by Wednesday, the team had spun up a new feature that killed the application’s performance like a toddler on an espresso overdose: fast, chaotic, and entirely unsupervised.
That’s when it hit me: I hadn’t built a system, I’d built a babysitting job.
A question has been raised about the future of the architect role with the rise of AI. If human-built software (and SaaS, as claimed by Microsoft’s CEO) is going away, what happens to the practice of architecture?
I’m rarely optimistic (the curse of architecture, I guess), but I feel safe.
Back in 2014, I was at a meeting with a prominent French bank about a challenging project. At the time, “low-code” was a fresh concept, and the bank aimed to build its own low-code IDE to let business analysts craft UIs and speed up delivery.
The team already knew each other from previous projects, so introductions were a formality. Our manager introduced everyone: “This elegant lady is the delivery manager, that serious gentleman is the team lead…”
When he got to me, the bank’s IT manager interrupted, winked, and joked, “The guy’s doing nothing!”
We laughed sincerely and moved on.
Being an Architect is like being a conductor1 in an orchestra. You’re not playing all the instruments, but your job is to make sure everyone is in concert [pun intended] and that the result is harmonious.
I once saw Simon Rattle conducting 6 Berlin school orchestras playing Edvard Grieg’s Peer Gynt Suite. As a matter of fact, they never worked nor rehearsed together before. Their first play was awful and cacophonic, but after multiple corrections and rehearsals, Rattle transformed the final performance into a beautiful and majestical piece.
After a heavy lunch break with a team, Dorian, one (among others) young and competent developer, enthusiastically asked me: “How does someone become an Architect, and what’s the path to follow and what to learn to be one?”
I wasn’t asked this question for the first time, and to be honest, I was never able to answer it properly.
During an after-work with some dear colleagues, one asked: “How can we define our success?”.
People started throwing answers like : by the customer’s happiness, by listing the greatest achievements, the metrics hit, by the completed tasks and goals, the career evolution or even by the gain accumulated.
Unsurprisingly, I was unsatisfied. These answers looked more like a standard pitch to succeed in an interview rather than deep thoughts.
In my opinion, one’s success can’t be measured only by corporate expectations; a career can’t be measured only by goals, achievements or accumulated wealth; a professional can’t be successful only by positive feedback or customer satisfaction.
And what about Architects, as the disgraced-and-always-blamed people in an organization ?
How can they measure their successes, especially since they only provide listening, more questions and rarely one option?
Most architects get pushed toward deeper specialisation over time. I went the other way, and I’ve grown comfortable with the ambiguity that comes with it.
The word “polyglot” has drifted well beyond its linguistic origins. For me, it describes an approach that values breadth over depth in any single stack.
I’ve always been fascinated and reflecting about the peacefulness and the respect that emerges when watching some masters doing their professions.
So, I spent lately some years time observing and trying to see the world through their lenses and may be, and if I’m good enough, adopt their skills and get inspired to improve myself personally and professionally.