Forem: Hatem Zidi

AI Didn’t Make Us Smarter. It Made Intelligence Cheap.

Hatem Zidi — Tue, 20 Jan 2026 11:11:20 +0000

AI doesn’t threaten intelligence; 
it exposes how little judgement most systems have.

I came across a post from an old colleague, questioning whether intelligence and knowledge still define who we are, now that AI can produce answers faster than we can formulate questions.

The idea itself isn’t new, but something about it stayed with me. Not because of the technology, but because of what it exposes when familiar markers of value stop being rare.

At that point, the discussion shifts. It stops being about machines and becomes a question of where human value actually sits.

This is not a story about AI replacing humans. Rather, it is about value moving away from knowledge and towards something less comfortable.

The Identity Crisis

For most of modern history, intelligence and knowledge functioned as a stable currency. Because of that, they became a convenient place to anchor identity, especially in professions built on expertise.

If you knew more than others, you mattered. If you could solve problems others could not, you were needed. Entire careers were therefore justified by being “the expert in the room”.

But, AI unsettles that arrangement.

Not through a sudden rupture, but through accumulation. Intelligence is no longer scarce, and knowledge is no longer accumulated slowly through years of exposure. Instead, it is produced, recombined, and delivered on demand, which increasingly turns what once differentiated individuals into something closer to a utility.

That shift is not merely technical.

It is personal.

I think that people are not afraid of machines becoming smarter. Rather, they are afraid of losing the thing their identity was attached to. The deeper fear is not replacement, but becoming ordinary.

Devaluation Before Replacement

The first visible effect of this shift is not replacement, but devaluation.

At the surface, nothing disappears. Code still matters, yet writing it is no longer a strong signal. Architecture diagrams still exist, although generating them has become trivial. Analysis is everywhere, which inevitably makes any single instance less impressive.

As this becomes normal, experience begins to blur. Juniors produce work that looks senior, while seniors feel their edge narrowing. Being “smart” becomes harder to see, and being “experienced” less decisive on its own.

I have seen design reviews where proposals looked flawless within minutes, coherent and confident. What took longer was realising that no one in the room was willing to own the long-term consequences of the decision.

This is usually where discomfort surfaces.

Some deny the shift and reduce AI to “just a tool”. Others lean too hard on it and start confusing speed with thinking. Many feel uneasy without quite knowing why, and drift towards complexity, jargon, and over-engineering. Not because those things help, but because they feel familiar.

What is really being lost here is status. Over time, effort stops translating cleanly into value, and visibility loses its power. Professions that built their legitimacy on expertise feel this first.

From Knowledge to Judgement

This is where the reframing becomes necessary.

I believe that human value was never rooted in knowledge alone, but in how that knowledge was used. As output becomes cheap, value moves upstream, away from execution and towards intent.

AI can generate options; however, it cannot own consequences. It can optimise locally, yet it cannot reason systemically. It can assist decisions, but it cannot be accountable for them.

Judgement, therefore, is not only intelligence.

It is intelligence that accepts responsibility.

In software architecture, this distinction is familiar. Getting a design on paper is rarely the hard part. The difficulty shows up later, in understanding what the system will tolerate, what the organisation will resist, and what the long-term cost will actually be. Quite often, the best decision is not to build at all.

That requires taste. Not taste as aesthetics, but as the ability to recognise which acceptable solution will age badly, which trade-off will hurt later, and where fragility hides.

I'm convinced that organisations will pay a premium for judgement precisely when the cost of being wrong becomes disproportionate.

This happens when decisions are expensive to reverse, when failure modes are asymmetric, and when a single mistake outweighs many correct choices. It also happens when technical decisions quietly carry operational, regulatory, or reputational consequences that surface long after delivery.

In those environments, execution is rarely the constraint. Direction is. Judgement matters because mistakes compound, and because someone eventually has to own them.

That said, there are also contexts where judgement should not dominate. Such as proofs of concept, short-lived tools, and low-risk experimentation. They benefit more from speed than deliberation. Recognising this boundary matters.

From Sailors to Navigators

For years, technical professionals were trained to be excellent sailors.

They learned frameworks, patterns, tools, and best practices, optimised routes, increased speed, and learned to manage storms. Execution became the measure of competence.

AI excels at sailing. It is fast, tireless, and precise.

But sailors do not choose destinations.

Navigators choose direction, define purpose, and judge whether the destination justifies the cost. AI accelerates sailing; navigation remains human.

However, judgement does not eliminate risk. It compresses uncertainty into conscious, owned choices.

Also, It does not scale easily, which means fewer people will operate at that level. Operating there is harder.

Final Thought

Because competing with machines on the “what” is unsustainable, the only durable advantage lies in mastering the “why”. In understanding intent, consequences, and direction rather than output.

Seen from that angle, work does not lose meaning; this change concentrates it, by trading the comfort of execution for responsibility.

That's the recalibration many of us were overdue to face, and one that will ultimately define who remains relevant in an AI-saturated world.

If you liked this post, follow me on my blog for more.

Stop Confusing Metrics with Quality

Hatem Zidi — Wed, 26 Nov 2025 14:37:35 +0000

Quality is subjective.  
Architecture is judgemental. 
So how on earth do we measure it?

Every architecture review, every design workshop, every committee meeting eventually hits the same wall. Someone asks: “But is this actually good?”

We pretend the answer lives in metrics. Response times. Availability. Coupling scores. Maturity models. Dashboards filled with comforting colours. We convince ourselves that if the numbers are green, the architecture is good.

That is the uncomfortable reality: half the time, those numbers are illusions. They tell part of the story.

I’ve witnessed perfectly green dashboards collapse the moment real business pressure appeared.

Two architects can stare at the same design and read entirely different realities. One sees elegant decoupling. The other sees over-engineering. One admires flexibility. The other sees unnecessary complexity.
Who is right? Both… and neither.

We all know that architecture lives in trade-offs, not in absolutes.

So is its quality measurable or not?

The real answer is even more uncomfortable: we can measure constraints, but we cannot automate judgement.

And this is where most organisations get it wrong.

If you remove judgement completely, architecture becomes a spreadsheet competition. The loudest person chooses the metrics. The metrics justify the decision.
Congratulations, you’ve just dressed up politics as engineering.

The HiPPO, Highest Paid Person's Opinion, does not disappear. They simply bring better charts.

But if you go to the other extreme and replace metrics with “experience” and “intuition”, you create a different problem. Quality becomes personal. Non-transferable. Everything depends on one strong architect. When they leave, the quality leaves with them.

That is not sustainable. That is organisational fragility.

Real architectural quality does not live in either extreme. It lives in the tension between them.

Metrics are essential. They create boundaries. They expose trends. They stop ego from running wild. Architecture fitness functions, dependency checks, performance budgets, DORA metrics, failure rates, these are not optional. They are your guardrails.

If you want to see what these guardrails look like in practice, I highly recommend Software Architecture Metrics¹; where the authors make a compelling case that metrics should be treated as vital signals for conversation, not just targets for validation.

But they are not your brain.

A fitness function can tell you that a dependency cycle exists.

It cannot tell you whether breaking it today is worth delaying a strategic launch tomorrow.

Metrics can show increasing complexity.
They cannot understand that this complexity is temporary and tactical, with a deliberate simplification path.

This is where judgement enters, not as a mystical talent, but as a disciplined and empirical reasoning process.

And that judgement must be made visible.

Through architectural decision records.
Through clear principles.
Through written trade-offs.
Through post-mortems that don’t hide the ugly bits.

In fact, you do not scale judgement itself.
You scale the story of how that judgement was formed.

That is how you avoid turning your architecture into a shrine to one individual’s mind.

Now comes the part that makes the business lean in.

The CFO might not care about elegance or purity, but they deeply care about the consequences of poor quality. They see it in:

Delayed product launches
Rising incident costs
Burned-out teams
Unpredictable delivery
Increased vendor dependency

That is architectural quality translated into money, risk and opportunity.

Quality is not a bunch of numbers.
But its impact on the business is brutally measurable.

Strong architecture is not loud. It does not need defending every week. It creates calm. It creates speed. It gives teams confidence instead of friction. It reduces drama instead of creating it.

And perhaps that is the most reliable indicator of quality there is: The absence of unnecessary suffering.

Quality was never about a perfect score on a dashboard; it’s about a system that does its job without constantly asking for forgiveness.

If you liked this post, follow me on my blog for more.

By Christian Ciceri, Dave Farley, Neal Ford, Andrew Harmel-Law, Michael Keeling, Carola Lilienthal, João Rosa, Alexander von Zitzewitz, Rene Weiss, Eoin Woods ↩

The Doubtful Architect

Hatem Zidi — Tue, 05 Aug 2025 09:17:56 +0000

 Show me an architecture no one questions, 
 and I’ll show you a system no one understands.

A few years back, I walked into a post-mortem where the architecture was being blamed for everything from latency spikes to the office coffee machine malfunctioning.

The architect? Well, he was calm. Unbothered. Certain.

“It’s not the design,” he said.

“The team just didn’t implement it properly.”

There it was: the dead giveaway. He wasn't doubting the design. He was defending it like gospel.

Right then, I knew.

The most dangerous architect isn’t the one who lacks answers.

It’s the one who never asks questions.

If you’re an architect or becoming one, doubt isn’t your enemy. 
It’s your sharpest tool.

Why Architects Must Doubt

Doubt isn’t indecision. Doubt is respect for complexity, for context, and for change.

It’s what keeps you curious instead of complacent.

Without it, you don’t explore. You just preach.

You don’t validate. You just defend.

And that’s when architecture stops evolving and starts rotting.

“The moment an architect starts believing their own narrative too much, they stop listening. They defend ideas instead of validating them. They treat solutions like doctrine. They mistake consistency for correctness.”

— From an older post

Once you slip into certainty mode, it’s over. You’re not solving problems anymore. You’re selling ideology.

And tech doesn’t care about your ideology, it just exposes it over time.

What Happens When They Don’t

Ever seen a team stuck in a bloated microservices hell because someone got overexcited after a Netflix blog post?

Or a Kafka pipeline duct-taped to a CRUD app with 12 users?

That’s not architecture. That’s tech theatre: overpriced, overhyped, and dead on arrival.

At one company I worked for, Jenkins was repurposed as a cron job scheduler in a high-volume data exchange system. Nobody could recall exactly why but the consensus was that it was “simpler to configure” and had a user-friendly UI.

As data volume grew, Jenkins’s well-known scaling limitations became a major bottleneck. It only scaled vertically, and vertical scaling has its limits.

Over time, the system evolved. Everything got tightly coupled to Jenkins: services, data flows, batch jobs, events, and configuration.

Removing it became a nightmare, like flipping over an entire table. Imagine trying that across 200 production environments.

    Idiocy is optional, always a choice.

This wasn’t just poor architecture. It was a perfect example of how idiocy is optional, always a choice.

Someone opted for convenience over foresight, and the technical debt paid the price.

When architects stop doubting:

Systems get overengineered: Without scepticism, every new feature turns into a grand project. Complexity balloons unchecked because no one questions if simpler works.
Teams stop challenging decisions: Doubt creates dialogue. Remove it, and dissent feels like insubordination. People nod, not because they agree, but because they fear speaking up.
Criticism feels like betrayal: When certainty hardens into dogma, any pushback is personal. Feedback becomes a threat, not a tool, and the system suffers in silence.
And the architecture solidifies into a relic nobody has the guts to question.

Balancing Doubt and Decision

Doubt doesn’t mean you freeze. You still make calls, you just know where to be sceptical.

You separate the big, game-changing questions from the nitty-gritty details.

You don’t get stuck debating every minor tech choice; you focus your doubt on decisions that shape the system’s future.

It’s about calibrated scepticism, questioning enough to avoid disaster but deciding enough to keep moving forward.

Be strategically doubtful: Should we build this at all? Centralised or federated?
Be tactically decisive: Which DB? Which caching strategy?

Good architects don’t know everything. They just know what to question, and when to stop.

They write decision logs.

They challenge assumptions.

They run pre-mortems before the system’s on fire.

It’s not wizardry. It’s operationalised doubt.

Doubt Is a Cultural Signal

If juniors don’t feel safe saying “This doesn’t feel right,” you’ve already failed.

A doubtful architect builds a team that questions, explores, and learns.

They create an environment where challenging the status quo isn’t a career risk but a necessity.

A dogmatic one builds a team that obeys, until they burn out or leave.

Want to measure maturity? Ask how often people revisit architectural decisions.

If the answer is “never,” you’re probably maintaining a fossil: a brittle system propped up by silence and fear, not trust and curiosity.

To make sense of all this, let’s map how doubt and decisiveness shape architectural impact.

Think of it as your mental compass for when to push, when to pause, and when to pivot.

The Doubt Spectrum

Here’s the architect’s mental model:

                                  High Doubt                                   

                                      ^                                        
                                      |                                        
                                      |                                        
                   Paralysis          | Strategic Doubt                        
                   (analysis forever) | (adaptive, robust)                     
                                      |                                                                             
                                      |                                        
Low Decisiveness   -------------------|------------------->  High Decisiveness 
                                      |                                                                              
                                      |                                        
                   Blind Faith        | Overconfident                          
                   (dogma, stagnation)|  Execution                             
                                      | (fast, wrong)                          
                                      |                                        
                                      |                                                                             

                                   Low Doubt

You don’t want to be slow.

You don’t want to be certain.

You want to move fast and doubt smart.

Final Thought

The best architects I know doubt themselves just enough to double-check assumptions, but not enough to stall.

They don’t cling to being right, they focus on being adaptable.

And they know the job isn’t to win arguments, it’s to keep systems alive.

Not just surviving, but adapting. Evolving with the business, the team, and the unknowns ahead.

Architects aren’t paid to be right. They’re paid to keep systems running despite being wrong, and to provide clear options when “it depends” is the only honest answer.

So doubt early.

Doubt loud, and often.

And design like the future will prove you wrong, because it probably will.

P.S. One Thing to Try Monday Morning

Before your next architecture review:

Pick one key decision and argue against it for 10 minutes.
Invite a colleague to do the same.
Use what you learn to refine or document the risks clearly.

It’s not about being negative, it’s about sharpening your view.

If you liked this post, follow me on my blog for more

“Errorless Architecture” Is a Myth

Hatem Zidi — Fri, 06 Jun 2025 13:47:25 +0000

errorless (adj)

Free from error, accurate, correct.

Being complete of its kind and without defect or blemish.

I stumbled lately onto a strange feeling: many of the architectures I review are overcomplicated, fragmented, full of flows jumping here and there.
And what makes it worse? The cost of development, the deployment, the running, the operations — just to keep the system alive — are astronomical.

Everyone argues it’s about anticipating every possible flaw:
A pinch of redundancy here, a teaspoon of fallback there. Secure this, protect that, isolate this, and wrap everything twice.

However, instead of ending up with “a state-of-the-art design,” as they expect, they end up with rigid, overengineered systems that are at best… stable.
But there’s one thing they all forget: adaptability.

I know some will start waving the flag of “clean architecture,” “decoupling,” or “microservices.”
But for me, it’s deeper than that.

"A good architecture isn’t about being errorless; it’s about being resilient — able to adapt without drastic changes to the whole system."

The problem is, most people confuse resilience with durability — as in strong and built to last a long time without breaking or becoming weaker.
But we all know that “errorless” and “flawless” design are myths.
Systems are built by people. People change. Teams change. Business needs pivot. APIs evolve.

The only constant in architecture… is change.

I’ve learned this the hard way, like most of us.
You build something, it works, it’s elegant — and then comes the change. A new requirement, a new constraint, a new team, or just time doing its thing.
Suddenly, your “errorless” perfect design becomes your worst enemy.
It can’t bend. It can’t adapt. It can only break.

That’s when you realize: the value of architecture isn’t in what it prevents — it’s in what it absorbs.

To me, resilience means building systems that bend without breaking.
It’s the difference between tweaking a config and rewriting half your platform because of a new requirement.

Grady Booch said it best:

"The best architectures are those that can evolve gracefully under stress."

On the other hand, architecture is stressful.
We, architects, are judgmental. The job is judgmental. Constant tradeoffs. Incomplete information. Pressure to decide. Pressure not to.
We live in a constant “what if” mode.

Which is where residuality, from Barry O’Reilly, comes in.
And I love how he frames it:

"The best design is the one that leaves the fewest irreversible decisions."

Residuality means designing for change — before change even happens.
It’s like laying down tracks but keeping the junctions open.

Don’t commit to tech too early.
Don’t lock your database schema on day one.
Don’t create tight couplings just because “it’s faster.”
These decisions always come back — like bad karma — and they’re expensive to undo.

We act like we’re building statues.
But what we really need… are sponges.

I also want to highlight that resilience isn’t about being bulletproof.
It’s about being flexible.

Stability might look safe. But it can kill adaptability.
That’s a trap in systems thinking: we add more structure to “fix” problems, and end up with a system that can’t move.

Or worse: a system that silently fails in the background while we admire its layers.

Fixes that fail? Seen that movie.
It’s called “Quick Fix” — and it always ends badly.

You want a system that can stretch. A system that learns.
One that gets better when things go wrong — not one that cracks under the weight of its own protection mechanisms.

So no — you don’t need an errorless architecture.
You need one that can evolve. One that doesn’t punish you for not predicting the future.

Because at the end of the day, ~~real~~ architects don’t fear change — they’re built for it.

If you liked this post, follow me on my blog for more.

Why Architects Won’t Be Replaced by AI Anytime Soon

Hatem Zidi — Thu, 13 Feb 2025 15:22:16 +0000

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.

Being an architect isn’t just about technical skills, checking quality attributes, or having a bunch of soft skills. It’s about forecasting behavior, anticipating change, and, more importantly, applying real systemic thinking—spotting patterns and understanding how they evolve across different contexts.

AI won’t replace architects, especially in large enterprises or complex systems. The trade-offs, alignments, and creative problem-solving—even innovation itself—require more than just data crunching. It takes awareness, intuition, and a mix of art, method, and elegance.

Architecture is about designing something that fits a purpose. And to get that right, we go through endless rounds of refining requirements and making sense of them. AI will (and already does) make people lazy—we see it in the declining quality of code and content.
AI can generate, but it can’t qualify or validate.
It speeds up output, but without intent, it just accelerates garbage.

Let’s be honest: no client is going to throw a vague “I need an application to handle my process and cost me less than now” at an AI and get a well-structured, risk-assessed, future-proofed solution without hallucinations.

That said, AI is a powerful tool. It’s already helping architects move faster, cutting through multiple technical domains, gathering insights, and automating the grunt work. That’s exactly what I’m doing right now—it’s making me more efficient, letting me focus on actual architecture instead of chasing documents and aligning contracts.

Just to remind you that architecture isn’t just about speed; it’s about judgment.

Take a large system migration—aligning security, compliance, cost, and scalability isn’t just a checklist; it’s an art. AI can assist, but it doesn’t have the strategic thinking to balance those forces effectively. It doesn’t see beyond immediate outputs, and it certainly doesn’t think long-term.

So no, I’m not worried. AI will change how we work, but it won’t take our work.

If you liked this post, follow me on my blog for more.

PS : ©️ Image by GETTY

When a clueless Salesperson got me into computers, Inadvertently

Hatem Zidi — Wed, 12 Feb 2025 14:58:53 +0000

So there I was, 8 years old, dragged to the shopping center by my dad because, apparently, shopping for socks is a family event. We’re walking through this temple of consumerism when—BAM!—I spot a computer showroom. Not just any computers. MSX/Sakhr machines.

These things looked like the future, like I had just unlocked a portal to infinite knowledge.

Now, let me tell you, these weren’t just computers. These were mythical beasts of technology designed to bring the wonders of BASIC programming, educational software, and a whole lot of confusion into people’s homes.

MSX/Sakhr was this Middle Eastern adaptation of the MSX standard, which basically meant it came with Arabic language support and, if you were lucky, some software that actually worked.

It was also provided with a very beginner book to learn BASIC, the famous yellow book, I'm sure it was the early version of the "for the dummies" series—except every time you tried to do something, the computer yelled "YOU IDIOT" at you.

Being a naïve, wide-eyed kid, I found an empty spot with a displayed computer, sat down, and told to myself, let me ask this wonderful machine a question—something profound, something that would shake the very foundation of my young mind: What’s the square root of 2?

Yeah! Because, at 8 years old, that was peak theoretical physics.

I spent hours—okay, probably minutes, but time is relative when you’re eight—staring at the keyboard like it was a puzzle, struggling to find the right keys with my tiny fingers fumbling over unfamiliar symbols.

Finally, I found the key labelled "Enter."

Perfect! That’s what I want! I want to Enter! I pressed it.

And then… SYNTAX ERROR.

Alright, cool, maybe I messed up. Try again.

SYNTAX ERROR.

Ah. The computer and I were in a toxic relationship—full of high expectations, poor communication, and relentless disappointment. And honestly, that was just a preview of every future interaction I’d have with technology. Have you ever felt like you were in a battle of wits with a machine and losing?

Frankly, I'm still losing mine to this day.

So, naturally, I turned to the all-knowing, tech-savvy, wise sage of the electronics showroom—surely a beacon of knowledge in my moment of need—and asked, “Hey, what do I do now?”

And this man—this highly trained professional in a tech showroom, this so-called "expert" who probably couldn't tell a byte from a bite—looked me dead in the eyes and said…

"I don’t know."

😱

Sir. Sir! This is literally your job!

I mean, I get it. Life is full of disappointments. You think you've found someone who knows what they're doing, and then they hit you with the technological equivalent of a shrug emoji 🤷‍♂️.

It's like going to a doctor who says, "Yeah, I dunno, maybe try some aspirin?" or a mechanic who looks at your car and goes, "Beats me, maybe it's possessed?"

And in that exact moment, with the clarity of a thousand suns, I knew.

Understanding computers wasn’t enough—I had to understand the people pretending to understand computers.

I was going to become a computer geek.

Because clearly, nobody knows what the hell is going on with these machines, and I’ll be paid for that.

But my dad, bless his heart, saw something in my eyes that day. He saw the spark of curiosity, the determination to figure out this confusing, infuriating machine. And so, he did what any supportive parent would do—he bought me that computer.

That moment changed everything, setting me on a path I'm still walking today.

And thus began my journey—not just from developer to software architect, but from hopeful problem solver to professional translator of human madness into machine logic.
A lifetime of chasing meaning, debugging existential crises, and questioning my own sanity one "It depends!" at a time.

My fate? To design systems that will inevitably be misused, to future-proof architectures against problems nobody has thought of yet, to explain the same concept fourteen different ways until someone nods—and then still asks, ‘Can’t we just make it a no-code platform?’

Forty years later, I still have it. It sits in my home office, a relic of an old era, a reminder of the journey I started. Every time I look at it, I remember that day in the mall, the frustration and the fascination.

Somewhere, deep in the binary abyss, the computer is still laughing—probably throwing an error I predicted some years ago, but nobody listened.

And honestly? Same.

If you liked this post, follow me on my blog for more.

Architects Are Useless... Until They're Not.

Hatem Zidi — Mon, 13 Jan 2025 08:54:40 +0000

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.

You may ask, why did he say that?

Let me tell you a story...

... And take you back a bit.

I once worked with a team (let’s call them Team Chaos). They struggled daily to resolve their problems or add new features, not because they were hard but because of their egos, foggy culture, and lack of will, of common practice and sense. Their product was clunky, delivery processes were atrocious, and the technical debt? Higher than Everest.

Coherence? Nonexistent.

Cohesion? Don’t even ask.

As an Architect, I tried to help ease the pain. I suggested small fixes: alignments, deprecations, and standardisations. Nothing earth-shattering. But they weren’t interested. Their comfort zones and glorified titles mattered more than progress.

Every meeting, every stand-up, every refinement felt like a déjà vu: “No, it’s too hard,” “It’s impossible,” “Not doable.” The energy spent clarifying and convincing was exhausting. Subsequently, good people burned out or left.

To top it off, they insisted that I wasn't needed and complained that I wasn’t helping solve their problems either. Irony? Maybe. Despite my flexibility and efforts, trust eroded, and synergy never took hold.

Now, contrast that with another experience—Team Synergy. Think of them like the bank’s team I mentioned earlier: skilled, mature, and autonomous. They understood the “why” behind the design and built on it accordingly. They were smart enough to acknowledge new ideas, challenged them thoughtfully, refined them, and turned concepts into concrete and functional systems. Watching them was like watching a Swiss watch: precision, elegance, and perfection in motion.

I remember well that I deliberately chose to step back with Team Synergy. After some weeks of guiding the “construction” and ensuring that everything was in its right place, I became irrelevant. When the bank’s manager questioned my decision, I told him, “I’m doing nothing. The team became 100% capable and autonomous.”

So, what’s the difference?

For the most part, Team Chaos was allergic to change. Mediocrity thrived and was outrageously contagious. Outsiders and fresh ideas were smothered under shallow pretexts like “value,” "backward compatibility," and “customer success.” They criticised more than they contributed and avoided any wind of change.

But what about Team Synergy? Well, They embraced change. They shaped goals together, held each other accountable, and worked as a unit.

In both cases, there is a tacit way of working: Either the team knows exactly how to do it, or they are hiding behind constant guessing, which, as a consequence, makes an Architect irrelevant or not.

This is just another cultural alignment.

The Unfair Slap

Just as I was questioning myself (midlife crisis, anyone?), I stumbled upon Ivory Tower Architect by Alex Ewerlöf. Another article bashing Architects, claiming they’re useless and redundant, that teams can rely on themselves to design their Architecture. Yet again, Architects are painted as unnecessary. Sigh.

Ewerlöf wrote in his post :

After 20+ years of software development, I have come to grow a specific despise for the title architect. Becoming an architect is one of my biggest professional nightmares.

That’s because people carrying this title typically:

Claim expertise over what should be in every engineer’s skillset.

Abuse power and cause friction.

Are avoided by skilled engineers.

In short: they are irrelevant!

Architect is a misnomer in the software world. It's a common fallacy to compare it to a building architect. The closest role to the building Architect is UX.

I’ll be honest. Reading that post crushed me. My last shred of self-esteem was gone. For a moment, I truly felt irrelevant.

The words convinced me to hate myself.

But then, I read it again. This time, looking for lessons, insights—anything to rebuild my perspective or to push me to consider quitting and becoming a sheep farmer.

What I found wasn’t clarity; it was contradictions, misconceptions, and hidden agendas. The article wasn’t just about Architects; it was about restructuring hierarchies, power dynamics, and roles. It also carried a personal grudge that overshadowed objectivity.

The biggest misconception? Context. Ewerlöf's mindset screams “startup culture”, glorifying generalists while dismissing specialists as bureaucratic obstacles. Sure, that works in small, agile teams. But in large, complex systems, that’s a recipe for chaos. Mature organisations need specialisation to manage scale, risk, and complexity.

Then there’s the push for “role multiplicity.” The idea that engineers should take on everything—Architecture, design, delivery—is unrealistic. It ignores cognitive and time limits, undermining together execution, quality and long-term strategy.

Worse, it misrepresents Architects. These roles go beyond engineer skillsets, tackling risk management, technical debt, and compliance. Ewerlöf disregards these contributions, misleadingly presenting Architects as redundant.

The criticism of Architects focusing on “high visibility, low impact” work—like diagrams and documentation—also misses the mark. These tasks are vital for team alignment and scaling in complex environments. The essay doesn’t clearly delineate when such work becomes counterproductive versus when it is essential for strategic alignment. This creates a contradiction: strategic planning and documentation are indispensable in scaling software systems but are dismissed as "low impact."

And then, I remembered the Architects I’ve seen over the years. Decent, hardworking professionals who burned out trying to bring coherence to chaos. They were blamed, disrespected—even fired—for failures often rooted in lousy engineering choices or broken systems they couldn’t control.

Do bad Architects exist? Absolutely. But so do bad managers, bad engineers, and bad customers. Should we declare them irrelevant, too?

The ivory tower isn’t exclusive to Architects—it’s a pattern of broken organisations and power abusers. But eliminating Architects entirely? That’s too radical, too simplistic.

Because the truth is, when done right, Architects aren’t just relevant—they’re essential.

The problem with Architects is that people cannot understand that they need them until they mature enough to understand that they need them.

-- A wise friend

So ...

Where and when do we need Architects?

Well, I believe that Architects simultaneously surf multiple expectations by addressing various needs. Here’s how:

System Coherence

Architects ensure the system works as a whole. They align teams to build scalable, maintainable, and interoperable systems while minimising technical debt.

They consider future/incoming quality attributs¹, Architects guide technical decisions that balance short-term delivery with long-term goals.
They ensure all parts work harmoniously without bottlenecks or redundancy.
They set clear boundaries between subsystems, keeping things decoupled but tightly integrated.
They identify risks such as security, compliance and performance and design solutions before problems arise.
When things go sideways, they step in to help fix issues and plan for systemic improvements, keeping the technical stability intact, especially in a crisis.

Cross-Team Collaboration

Architects aren’t just technical experts but also communicators. They bridge communication gaps, by facilitating collaboration between engineering, product, and leadership teams.

Mentorship and Upskilling

Good Architects mentor. They pass on knowledge, spread best practices, and help engineers grow. By doing so, they strengthen the team’s foundation and resilience.

Causal Relationships

Architects have a knack for figuring out why things break. They dig into root causes, fix systemic issues, and improve efficiency across the board.

While Architects play a crucial role in maintaining coherence, fostering collaboration, and mentoring engineers, the real question remains: How do these actions translate into tangible benefits for the organisation and the team?

Let’s break it down. Architects don’t just create blueprints and set standards—they actively drive change and enable teams to work more efficiently, solve problems proactively, and scale successfully. Their influence goes far beyond design decisions; they’re key players in shaping an organisation’s ability to adapt and thrive.

On the other hand, when it comes to planning a new feature, a software, a product, or a mission, we as engineers must consider several key dimensions when bringing together a team of professionals.

These factors help to determine how best to align the team and resources for success; I can mention :

Team's maturity
The system and the ecosystem complexity
The rate of change
Organisational Structure
Cultural & Mindset Alignment

Choosing these dimensions isn’t arbitrary—it’s rooted in reality. Team maturity determines whether the group can self-manage or needs guidance. System complexity ensures the team’s skills align with the problem’s depth. Rate of change measures adaptability to shifting priorities.

Likewise, Organisational structure shapes how decisions flow and teams interact. And cultural alignment is the glue that keeps everything together.

I believe that by ignoring them, you risk chaos—miscommunication, mismatched expectations, and wasted effort. Understanding these dimensions helps to provide the right balance of oversight, autonomy, and structure for each team and project.

However, I'll focus on the 3 first dimensions. I think that Structure and Culture are not fully within the scope of the Architect. They are more related to the company itself, its DNA, identity, core values, and, above all, the management.

Surprisingly, Ewerlöf was right. Architects can be irrelevant, and here is when.

Team's Maturity vs Complexity

As we can see from the blue area, the Architect's relevance grows with system complexity and reduces with team maturity. In simple systems, experienced teams can self-manage without external guidance. However, in highly complex ecosystems, Architects are indispensable, managing coherence and interdependencies while mentoring junior teams to navigate technical challenges and fostering their ability to handle future Architectural responsibilities independently.

Team's Maturity vs Rate of Change

Same, the need for an Architect increases when the rate of change and the team's maturity combine. In dynamic systems, Architects focus on adaptability, guiding junior teams through transitions and mitigating chaos. In stable environments, their role shifts to maintaining technical debt. With mature teams, Architects provide strategic advice, ensuring long-term optimisation while enabling the team’s autonomy.

Rate of change vs Complexity

An Architect becomes crucial in high-complexity systems undergoing rapid change. They manage interdependencies, scalability, and abstractions while ensuring adaptability to evolving requirements. In simpler systems or stable environments, their role shifts to optimising long-term performance and reducing technical debt. By balancing these dimensions, Architects safeguard coherence while enabling the organisation to navigate technical and strategic challenges effectively.

How do you stay a relevant Architect?

Well, Ewerlöf explained it ~~somehow~~ well in the section "How not to become an ivory tower Architect?" of the same post. However, I have already written various blog posts about:

5 Behaviours of Top Architects², the qualities Architects should embody to thrive
Architects Aren’t Made in Classrooms³, it’s about real-world skills and creativity, not just theories
Lessons Learned as a software Architect⁴, where I shared practical insights from my own journey.

Each of these posts dives into specific traits, mindsets, and practices that help Architects not only stay relevant but thrive in their roles.

What is An Architect?

This isn’t the title of another Matt Walsh documentary but still, it’s a real question about identity crisis in our industry. Is an Architect a position? A title? A role? Or just another misunderstood label we can’t quite define?

I was never one for promotions. Titles never did much for me—they're abused, misunderstood, and, frankly, subject to too much interpretation. Some people love them, others hate them, but in the end, they’re just tools to feed the ego, hint at importance, or claim more power and money.

Titles vary—company to company, person to person, experience to experience. They don’t tell you who someone really is or what they truly contribute.

We never hear about a senior carpenter, a principal farmer or a distinguished nurse, yet we know exactly what those people do. And we admire their experience without questioning it. Additionnaly, In the military, a rank speaks volumes, but in tech? We’ve diluted the meaning of titles, twisting them into strange names, roles, and stretched job descriptions that often blur the lines of responsibility and authority.

As much as I might disagree with the obsession over titles, I’ll admit—I’ve worn the "Architect" title. It’s a role, a task, yes, but also something more profound. Over time, I played many roles—mentor, leader, and learner—but I chose to commit to being an Architect. I wanted to master it, share my knowledge, and help others with some wisdom to navigate and build increasingly complex systems.

But let’s not forget: Architects can’t afford to be reactive. They anticipate, plan, and act without speculating. But let’s face it: sometimes we get it wrong. And that’s okay. We adapt and overcome. It’s part of the job.

Faith

If there was only certainty and no doubt, there would be no mystery. And therefore, no need for faith.

— Conclave, 2024

That quote struck me as I recently watched Conclave. It shouldn't be interpreted as something solely tied to religion. Faith, in some strange way, exists in Architecture, too.

Faith in architecture is about seeing what isn’t there yet and convincing others it’s worth building. It’s never just diagrams, metrics, or clean code. It’s about believing in the potential of what a system can become, even when all you have is a blank canvas or a pile of legacy spaghetti code.

Faith is what pushes you to stand your ground when stakeholders ask for shortcuts⁵ that compromise the future and the sustainability of your system. It’s what helps you articulate a vision so clearly that even the most sceptical engineer or hesitant manager begins to see it, too.

But don't get me wrong, faith isn’t blind optimism. It’s grounded in conviction and tempered by experience. It’s knowing that while the path ahead may be unclear, the destination is worth the journey. It’s having the courage to make decisions, even risky ones, and owning their consequences—good or bad.

Faith is what keeps you moving when complexity feels overwhelming, or when the team hits a wall. It’s that quiet belief that challenges can be untangled, systems can evolve, and chaos can be shaped into something coherent. And more than that, it’s contagious. As an architect, your faith inspires others to trust the process, take ownership, and push boundaries.

At its core, faith in architecture is about creating alignment—not just in systems, but in people. It’s about building bridges between what’s possible today and what’s achievable tomorrow, no matter how daunting the gap may seem.

You may say, but is this a role of the lead team, a staff++, or a manager? Maybe, but just ask yourself: who holds the full vision?

Final Thoughts

Alex Ewerlöf’s post was a sharp wake-up call, reminding me to question the role and its value. For that, I thank him. But his sweeping generalisations and guru-like tone? That part didn’t sit well with me. Yet, in some strange way, it helped me remember something vital: I’m a decent Architect, and that’s enough.

If you liked this post, follow me on my blog for more.

What great leaders don't do after you resign

Hatem Zidi — Wed, 18 Dec 2024 14:33:57 +0000

If, after quitting your job, you hear or get notified about your ex-leader doing these :

Speaking negatively about your departure
Undermining your decision by criticizing you, your new role or company
Attempting to make you feel guilty
Spreading resentment throughout the organization
Taking the resignation as a personal attack
Prioritizing their own interests over those of the team
Being absent or unavailable for the team during the transition
Spreading gossip about you
Delaying or writing vague performance appraisals or recommendations for you
Displaying an "it's all about me" attitude
Failing to acknowledge their own mistakes or shortcomings
Blaming others for failures or problems within the team

These behaviours scream insecurity, selfishness, and a lack of confidence in building and retaining talent. They crush team morale, erode trust, and send a clear message to the rest of the team: 'You’re disposable too.'

It’s not just bad for the team—it’s bad for business.

Leaders who act this way torch bridges, kill future networking opportunities and stain their professional reputations. Word spreads fast. Negative reviews pile up, and soon enough, the organization's name takes a hit in the market.

And here’s the kicker: when companies let this kind of behaviour slide, they’re not just losing one employee—they’re poisoning the entire culture. Employees notice the lack of respect, and it spreads.

Soon, toxic leadership becomes the norm. Good talent walks out the door, while the rest stay stuck in a demoralizing environment.

So, to the companies hosting these managers, understand this: your culture is at risk.
Allowing this type of behaviour means accepting a cycle of low morale, high turnover, and a reputation that will be hard to shake.
Don’t wait until your best people walk out the door.

Fix it now, before it’s too late.

I hate "Quick Wins"

Hatem Zidi — Sun, 24 Nov 2024 17:30:04 +0000

"I hate and categorically refuse quick wins", I angrily yelled.

The managers in the meeting jumped. They weren't used to seeing me lose my zen and calm temper so often.

"I have a huge ethical problem with this organisation's culture of quick wins. We are adding more layers of band-aids before even healing the scares", I continued.

As the discussion went on, they insisted on not agreeing, and I preferred to end the meeting there. We slept on it.

That night, as I was getting ready for dinner, my wife asked me why I was yelling at my office in the afternoon.

I summarised the incident as follows: we have a service in our product that is costing us opex and cloud bills, that is worldwide exposed, threatening our security and most of all, it's in-house made and redundant with an already managed services from our cloud provider. I wanted to remove that service, reduce the surface attack, decrease our technical debt and mostly ease the pain of our operators and customers, but the managers think that it's very long to do, and they prefer to hide it under another abstraction/UI without changing it because it's quicker, it's faster and provides a quicker "value".

Being a VP herself, she asked me, "I know that I don't have the full context, but what they are suggesting seems to be really a quick win; why are you against it?"

But ~~since I can't yell at her and~~ because I know well that she was really curious to understand how her stubborn Architect of a husband functions, I tried to structure my thoughts, and here I'm sharing with you what I told her.

If we rely on the Impact/Effort Matrix, quick wins are obviously the high impact/low effort area, which I read as the best balance between what we have to provide for the most effective value in the *long term*.

But as with great concepts, they are adapted, misinterpreted and stretched to something else. That being said, we engineers get attracted quickly to quick wins because we think that:

They steer the focus on urgent pain points,
They announce visible progress,
They give a perception of productivity,
They provide a feeling of risk reduction,
... and the Technical Debt can wait

However, let me start with this: [These] Quick wins are like quick shots of dopamine; instant gratification, but the crush later hits harder.

Nota Bene: In this post, I'll focus on this misinterpretation of quick wins.

Why are quick wins bad?

The answer really depends on the priorities and the stage of the project, but quite often, they all end in what I concluded:

- Technical Debt Accumulation
- Misaligned Goals
- Short Time Focus
- Inconsistent User Experience
- Compromised Architecture

Technical Debt Accumulation

Quick wins are like patching a leaky pipe instead of fixing the plumbing. Sure, it works for now, but the underlying problem grows and with it, technical debt.

Over time, this debt amplifies and compounds, slowing development and inflating maintenance costs.
Consequently, your team will spend more hours untangling messy code than building new features or innovating. Maintenance costs will skyrocket, and even minor enhancements will suddenly become monumental tasks.

What is the actual cost of these "quick" fixes? A[nother] lost momentum and an exhausted team.

🟡 As Architects, we're not just coding for today; we're building systems that need to endure. Fix it sustainably now, or pay the price later—with interest.

Misaligned Goals

Chasing quick wins often prioritises "fast results" over strategic outcomes. It's like sprinting when you should be running a marathon.

This mindset creates a culture of reactivity: patch what's broken now and figure out the rest later.
When speed becomes the goal, the real priorities, such as innovation, strategic planning, and long-term vision, all take a backseat. Teams end up firefighting instead of building something meaningful. The result? The product no longer aligns with its true goals.

🟡 Real progress isn't just about speed; it's about direction. As Architects, we should ask ourselves, "Are we solving the right problem or just the fastest one?" Because speed without strategy isn't progress; it's just running in circles.

Short-Term Focus

Quick wins are distractions dressed as progress. They are like shiny objects: tempting but distracting. They fix what's visible, putting out fires while ignoring the gas leak waiting to explode.

The result? A system that looks fine on the outside but is corroded with hidden cracks. Over time, these cracks widen, and suddenly, the whole thing isn't scalable, maintainable, or even usable. The short-term focus of quick wins trades real progress for the illusion of it.

🟡 Sure, they're tactical and feel productive, but they're often just glorified band-aids. Instead, Architects need to think long-term. Are we solving for today, or are we laying a foundation for tomorrow? Survival isn't Architecture. Building something that lasts is.

User Experience

Quick wins can fix your today's headache, but they often create tomorrow's migraine for users.

Imagine a product with different types of UI: one is sleek and modern page, the next looks boxy like it's stuck in 2000, and a third is so cluttered CLI where you can't find any reliable output. That's the result of Patchwork Design Driven by quick wins instead of a cohesive vision.

Small patches solve immediate issues but create inconsistencies that confuse users and hurt the product's identity. A fragmented workflow frustrates the user. Users don't care about how fast you ship fixes; they care about a seamless, intuitive experience.

When we chase speed, we lose sight of the user. And without users, even the most technically advanced products will fail.

🟡 As Architects, we're not just fixing problems but also designing journeys. And journeys built on patches lead straight to frustration. Build the experience, not just the feature.

Compromised Architecture

Think of your Architecture like building a structure with LEGO. Quick wins are like snapping pieces together without checking the instructions. In the end, you get something that looks fine at first glance, but try to add another layer or move it, and the whole thing wobbles or falls apart.

When you build for immediate results, you create an Architecture that's "good enough" for now but can't handle future challenges. Scalability? Out the window. Security? An afterthought. Performance? Patchy at best.

A sustainable Architecture needs a solid foundation: one that can support the weight of future features and growth. Quick wins tend to sacrifice this foundation, leaving discrepancies that grow with time. And here's the harsh truth: aligning those discrepancies later costs far more than doing it right the first time. You'll face rework that's not just expensive but disruptive. Systems will break when you least expect it, and economies of scale and speed become a nightmare.

🟡 As Architects, our role isn't just to address today’s challenges but also to prepare for tomorrow’s opportunities.

Just Ask yourself: are you building the foundation for a skyscraper or assembling a fragile house of cards? Quick wins might look impressive now, but solid, thoughtful Architecture is what keeps the whole thing standing when the pressure comes.

Real-life cases

There are countless examples of quick wins that backfired spectacularly, leaving behind a trail of chaos, lost trust, and staggering costs. We can pick the examples of the Volkswagen Dieselgate Scandal or Facebook's "Move Fast and Break Things" Era and how they really hurt them.

Volkswagen Dieselgate Scandal

Volkswagen’s shortcut to glory by putting cheat devices to dodge emissions standards, looked genius until it didn’t.

In 2015, the world saw through the charade. Billions in fines, massive recalls, and a global reputation in tatters became their legacy. What started as a "quick win" for passing regulations became a $30 billion catastrophe. The real cost? Trust. Customers, once loyal, saw betrayal where innovation was promised. It’s a painful reminder: cutting corners might save time, but the fallout costs everything you were trying to protect.

Facebook's "Move Fast and Break Things" Era

"Move fast, break things" sounded revolutionary until things truly broke. Facebook’s obsession with rapid deployment ignored the brewing storm of data privacy and platform abuse.

The Cambridge Analytica scandal ripped the curtain down, exposing the cracks left by this reckless approach. Billions in fines and a global trust crisis followed. Facebook had to pivot from speed to responsibility, spending years patching up its damaged image. This wasn’t just a broken motto; it was a hard-learned lesson in accountability.

Okay, I admit I wasn't that structured when I told my wife why quick wins are bad. But after I went quickly on the whys, she asked me about the hows and, as an Architect, how I overcame them.

Well...

How Architects Overcome Quick Wins?

- Adopt a Long-Term Vision
- Prioritise Root Cause Analysis
- Prioritise Strategic Planning
- Promote Incremental Delivery
- Educate Your Stakeholders
- Emphasise Code Quality & Technical Debt Management

Adopt a Long-Term Vision

To avoid falling for quick wins, Architects should adopt a long-term vision. Start with the end in mind, backward thinking is your secret weapon. This approach means working backwards from where you want to be, not just where you are.

Align everything with your product’s strategic goals, scalability needs, and user experience roadmap.

Does the solution contribute to the bigger picture, or does it simply patch up the immediate problem?

If you focus on the future, the decisions you make are toward the direction of sustainable growth. By extension, you stop looking at how to get a temporary fix that will eventually be more expensive.

👉🏻 Never lose track of what is sustainable.

Prioritise Root Cause Analysis

Resist the temptation to treat the symptoms alone. Instead, dig deeper with the 5 Whys technique; it’s simple but powerful. Take the time to truly understand the root cause before jumping into solutions.

Too often, quick fixes are just band-aids that cover up the real problem, leaving you to rework things ad nauseam. By prioritising root cause analysis, you ensure that your solutions target the heart of the issue.

This approach not only saves time in the long run but also prevents those frustrating cycles of constant rework.

👉🏻 Fix it once, fix it right.

Prioritise Strategic Planning

Stop chasing fires and start planning strategically. Use tools like the Impact/Effort Matrix to separate urgent matters from truly important ones.

Build a roadmap that isn’t just a reaction to today’s problems but a guide for tomorrow’s growth. Set milestones that balance quick fixes with high-impact, long-term goals. This keeps the team aligned, focused, and moving toward a vision instead of constantly shifting gears.

Strategic planning isn’t about ignoring urgency—it’s about ensuring that urgency doesn’t derail the bigger picture.

👉🏻 Plan smart, act smarter.

Promote Incremental Delivery

Incremental delivery is your ally in balancing short-term wins with long-term sustainability. Deliver solutions in manageable, well-thought-out pieces that bring immediate value while safeguarding your Architecture’s integrity. Advocate for Agile practices in your organisation.

Instead of rushing a complete solution, focus on what moves the needle now without jeopardising the bigger picture. Each increment should act as a building block, not a patch.

This approach keeps momentum strong, ensures quality, and builds trust with stakeholders without compromising the system you’re creating for the future. Build step by step, but always with purpose.

👉🏻 Start small, but think big.

Educate Stakeholders

Education is your secret weapon.

Help your stakeholders see beyond the allure of quick wins by explaining their hidden costs, such as technical debt, fragmented user experiences, and rework nightmares. Show them how short-term gains can sabotage long-term goals. Use real-world examples to bridge the gap between business priorities and technical realities. Leaders who understand the stakes are more likely to back sustainable decisions.

A well-informed team isn’t just supportive—it becomes a partner in building a future-ready Architecture.

👉🏻 Communication turns scepticism into collaboration.

Emphasize Code Quality & Technical Debt Management

Build a culture where clean code, regular refactoring, and managing technical debt are non-negotiable. Establish clear guidelines: when to tackle debt, how to prioritise it, and how to measure its impact.

Technical debt isn’t just a developer’s problem—it’s everyone’s.

Vouch for automation, Continuous Integration/Continuous Deployment (CI/CD) tools and practices; they are your secret sauce.

Remind your team that shortcuts today mean speed bumps tomorrow. By embedding quality into the process, you’re not just coding but investing in stability, scalability, and sanity. Long-term stability always beats quick-fix chaos.

👉🏻 Code quality isn’t a luxury; it’s your safety net.

Final Thoughts

I'm not sure if I've convinced my wife, as I also tried to share these thoughts with my fellow managers. Undeniably, Quick wins may feel like victories, but they’re often just traps disguised as solutions; they cost more than they deliver.

As Architects, our mission isn’t just to solve today’s problems—it’s to build systems that last.

Trade short-term fixes for long-term impact. Focus on clarity, strategy, and collaboration to create something sustainable.

The real win isn’t in how fast you deliver; it’s in the impact you create. Design with purpose, plan with foresight and ensure your Architecture endures the future.

If you liked this post, follow me on my blog for more.

5 Behaviors of Top Architects

Hatem Zidi — Tue, 29 Oct 2024 15:29:56 +0000

Being an Architect is like being a conductor¹ 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.

What made him succeed? How was he able to make everybody listen to him? How did he turn chaos into harmony? How did he bring out the best in every player?

Similarly, as an Architect, how can you work effectively? How do you manage to keep everything well-balanced and in sync?

In this post, I'll share with you what I think are the most essential five key behaviours that'll help you not only join the club of the chaotic world of Architects but also thrive in it.

TL;DR?

1. Listen Actively, Talk Eloquently
2. 360°, System Thinker
3. Ensure Coherence & Alignment
4. Change Catalyst
5. Raise the Bar

1. Listening Actively, Talking Eloquently

Unquestionably, good listners are focused people, they are commited to digest information and respond constructively. An Architect must fully understand tons of requirements, concerns, and limitations of stakeholders, technical teams, and end users. Thus, they have to pay close attention to details and don't be afraid of asking clarifying questions.

We have always heard that The devil is in the details. As an Architect, this adage must be part of your daily routine when discussing with your peers and customers to grasp both explicit requirements and the underlying needs that might not be directly stated.

On the other hand, we Architects love to talk and share our thoughts, opinions and findings, especially after absorbing considerable information. However, the language can change according to the audience and the level of complexity of the ideas.

Clear, concise, and impactful communication helps align everyone towards the same goals and lets them resonate with diverse audiences, technical and non-technical alike.

"How can I become an eloquent, active listener?" you may ask. Well, there is nothing fancy here or specific to the IT world.

First, Active listening isn't just about staying quiet; it's about fully understanding.

With this in mind, hold your thoughts to avoid interrupting. It's tempting to jump in but give the speaker space.
Next, ask the whys and the motivation. Don't assume; dig deeper into their reasoning. And don't forget to clarify.
Ask about the definition of key terms and the meanings behind common words. People often use the same words but mean entirely different things. By getting specific, you cut through the confusion.

Likewise, Eloquence is about delivering your message with precision, intention, and relatable imagery, making sure every word lands. Becoming eloquent means making your ideas stick.

First, simplify complex ideas. If you can't explain it simply, rethink it. Clarity beats jargon every time. Choose words with purpose. Every word should count, no fillers, no buzzwords.
Second, use metaphors. They turn abstract concepts into something tangible. Think of metaphors as bridges between what you know and what they understand.
Lastly, practice speaking slowly and thoughtfully. Give yourself time to think and your audience time to absorb.

An Anecdote

I once found myself attending a panel with stakeholders from a bank's IT department. We were tasked with building the bank's own development framework from scratch.

"A framework?" I thought, "That's huge." Why go for a new one when the market's flooded with options? Is it for development or business? Internal use or public? But I kept those thoughts to myself, waiting to hear them out.

At first, our salesperson ~~boringly~~ spoke for a long moment about our company's capability to build frameworks, really pushing the point. Then, out of nowhere, they gave me the floor to pitch more. I thanked them, but instead of pitching, I asked the panel a straightforward question: "Why do you need a new framework?"

They started explaining, and I listened, entirely silent, just taking down notes. The salesperson wasn't pleased, though. They kept giving me those you-better-say-something looks, which I ignored. When the panel finished, I followed up with a few more questions based on my notes. They went over their motivations again, and I kept quiet, taking it all in. The salesperson, still unhappy, poked at me with their eyes, clearly irritated by my silence.

It turns out they didn't need a whole new framework after all. What they really wanted was a set of dedicated UI components to standardize the look and feel of their SPA² development—something that would speed up delivery by providing ready-to-use business interfaces. Their initial request was exaggerated and misleading. The real scope? Completely different. And the outcome? Not what was first implied.

Being an active listener in this case helped me uncover the actual need, shift the focus on building what they wanted, and gain the trust of the stakeholders by genuinely understanding their goals.

As for the salesperson? Well, we learned to work together. They can sing, but I set the tempo.

2. 360°, System Thinker

Ever been in that nightmare where the amount of ~~spaghetti~~ dependencies in the system is so large that a slight change in a corner can introduce a meltdown in an utterly unrelated corner?

The Butterfly effect³, does it ring a bell?

Being holistic as an Architect means thinking beyond the immediate fix and influence of various technologies, tools, or methods. It means ensuring that decisions made at one system layer align with others, from infrastructure to applications and the business side.

Thinking holistically is essential to avoid siloed or disconnected designs, ensuring that the system works as a coherent whole, not a patchwork of parts, and preventing inefficiencies and future headaches.

For a fact, Architects must practice System Thinking and view systems as a whole, understanding the causality between components and their entourage and how they interact with each other.

This may involve assessing not only individual technical elements but also the broader context where they operate, including business objectives, user experience, scalability ...

I strongly advise you to read Learning Systems Thinking by Diana Montalion, which gives an actionable, tech-specific guide to mastering systems thinking. No theories there, it's about improving your Architectural approach in a way that's tangible and immediately useful.

To dive into Systems Thinking, here's where you need to focus:

Observe and Analyze Patterns Start spotting the patterns in your work, teams, and projects. Don't just notice what's happening—ask why it's happening. Systems thinking is about understanding what drives these patterns. You're training yourself to see beyond isolated events and to grasp the structure behind the scenes.
Practice Mapping Systems Grab a pen, draw it out. Map the system, lay out the components, relationships, and feedback loops. This isn't just a drawing exercise; it's a way to connect the dots and see the flow.
And mostly, you need to Learn to See Beyond Symptoms. Architects don't just treat symptoms; they dig deeper and seek out causes. If there's an issue, don't just fix it, but understand it. Ask "why" repeatedly until you hit the root cause. This 5 Whys technique will shift your focus from quick fixes to real solutions.

An Anecdote

During a workshop with reps from a well-known French oil company, we were digging into a change request for a BPMN process aimed at syncing key policies between the engineering, logistics, and safety departments.
Among the group was an experienced, white-haired gentleman, the Chief Enterprise Architect. We'd built a solid rapport over past projects, so there was mutual trust and respect.

The change? Yeah, it wasn't easy. The workflow was full of dependencies, and we kept bumping into edge cases, making every step more difficult. The Chief EA wasn't letting anything slide either and was very demanding as he was smartly dodging simplistic and quick solutions by pointing out the effects and the potential blockages in every solution we proposed.

After hours of brainstorming, mapping impacts and making sense of it all, I remember that I was leaning to my backpack searching for some painkillers for the headache that started hitting me, when Chief EA interrupted the group, asking: "Hold up, people! What's the best tool that we can use here?".

The room went silent; everybody glanced at each other, scratching their heads and threw out suggestions.

With a grin, he just gracefully waved his hand, smiled, winked at me and pulled out his own headache pills. "Folks!" he said, "we need more of this!"

3. Ensure Coherence and Alignment

I'm 100% convinced that Architects are the guardians of coherence in any system. If a system feels like a messy puzzle where things don't fit elegantly together, trust me! Something has gone wrong in the Architecture.

Coherence means every part of the system fits within the bigger structure—technical consistency, design principles, and alignment with strategic goals are all in sync.

Here's the thing: An Architect isn't just drawing diagrams and walking away. He has to mediate between worlds, ensuring business, development, and operations aren't in isolation. Each has its own language, goals, and pressures, but the Architect aligns them, connecting business needs with technical realities.

This isn't just about ticking boxes; it's about making sure what's being built is feasible, efficient, delivers value and drives impact.

How do we learn and enforce coherence? I'll say ...

Step in as the bridge between different teams, voices, and agendas. Be the Mediator. Coherence isn’t about picking sides; it's about unity. Get everyone aligned on the same wavelength.
Look at what worked (and didn't) in similar projects. Real-world lessons are pure gold for building coherent, effective systems.
Think holistically. Remember? See the whole system, not just pieces. Coherence is about making every part work together seamlessly.
Talk, clarify, and repeat. Misalignment usually comes from miscommunication. Coherence thrives when dialogue flows openly.

An Anecdote

My favourite Stoic Product Manager (PM) raised concerns from different stakeholders about how customers currently access our SaaS product. We needed to enhance this, ensuring a seamless customer experience with our backend components without compromising security or operational efficiency.

Engineering jumped in right away, suggesting we hide the existing access component behind a new layer, adding a totally new facade that will forward everything to wrapped automated scripts. On paper, it looked like a quick win, but to me, it was just another layer of duct tape, adding components and complexity while doing nothing to fix the underlying rust.

Maintenance would only become more painful.

The PM aimed to reduce friction for users and operations, while engineering's agenda was to move faster.

My intention, however, was to simplify. I wanted to lean everything into a singular approach that would deliver better security, controlled access, and minimal operational effort while reducing technical debt at best.

Initially, my proposal seemed heavy and slow to implement. But I knew the long-term coherence of the system would pay off. The final proposed design drastically reduced our code footprint by eliminating redundant components, enhanced security by limiting the attack surface, and unified authentication for all users.

What's the key lesson? Well, coherence isn't just about solving today's problem; it's about aligning business, technical, and operational goals to create a sustainable system. What seemed like a slower approach upfront actually saved us significant time and headaches down the road.

4. Change Catalyst

Change is the only constant

... and Architects must step up as Change Catalysts. We're not just building systems but driving transformation.

While many teams get stuck in the now, we are already looking ahead and thinking about what's next. The present isn't where we like to hang out.

Whether adopting new tech, reshaping business models, or guiding teams through new processes, Architects dig deep to spot opportunities and push for tangible improvements that elevate the organization.

But change? It doesn't come easy. People naturally resist, and that's where Architects raise. Our job is to help everyone move past the hesitation, get people on the same page, and plant the seeds of change. Easing reluctance, pulling people forward, inspiring them to step out of their comfort zones—it's our daily task.

You, as an Architect, must foster agility and advocate for flexible and incremental delivery. Design systems that don't just meet today's needs but can absorb future changes without collapsing.

Moreover, Architects create a culture of continuous improvement where innovation thrives, teams are empowered, and change is something everyone's ready to embrace.

Do you want to spark real change? Here's how to get there:

Change needs momentum. Master the Art of Influence. Influence is your fuel. Inspire, persuade, lobby and rally people around your vision.
If you can't see the future, no one else will. Sharpen Your Vision. Define what change looks like and why it matters, and make it crystal clear.
People follow those they trust. Show up, listen, and stay consistent. Trust is the bridge that carries change.
Talk is cheap—show them the way. Lead by Example. Embrace change yourself; people will follow because they see you living it.

An Anecdote

It was a chilly evening when I stepped into the ~~vitural~~ conference room, packed with ideas to drive meaningful change. I believed we were on the edge of something transformative. The goal? A total change in our target Architecture to enhance our product and our development process. I envisioned a united team, all pulling in the same direction.

But reality quickly dashed my hopes.

Every effort I made to connect our goals fell flat. I watched frustration grow as voices rose, opinions clashed, and an invisible wall formed between us.

The team was fragmented, and the lack of cohesion was palpable. Each member was pulling in different directions, locked in their own priorities and agendas. The developers saw only their code, the operations team couldn't see past their daily grind, and Management just didn't want to invest. I felt like I was trying to steer a ship with a crew that didn't even share the same map.

At that moment, I realized I couldn't force change without unity. I walked away from that experience with a heavy heart, knowing that influencing others requires patience, lobbying, and a lot of concessions to promote genuine connection and understanding.

The Transformation? Meh... it was a forgotten document in their drawer.

5. Raise the Bar

Well, "good enough" isn't good enough.

There are no two words in the English language more harmful than "good job".

-- Terence Fletcher - Whiplash (2014)

Great Architects inspire their teams to aim higher, pushing beyond the mindset of merely "getting the job done." By instilling a focus on innovation, quality, and meticulous attention to detail, these Architects set the tone for excellence.

Setting high benchmarks is vital. Whether in design precision, performance, security, or whatsoever, raising the bar means introducing best practices, backing new tools, and ensuring the team understands what quality truly looks like.

Mediocrity is contagious

High standards aren't just about pushing for "perfection"; they're about creating a baseline where everyone knows what excellence means and feels empowered to pursue it.

Architects aren't the smartest people on the team; they are the ones making everyone else smarter.

An Architect is an IQ amplifier.

-- Gregor Hohpe

Then there's mentorship. True Architects don't just lead; they teach. They try hard to bring all members up, guiding them to understand the nuances of delivering high-quality work. This ripple effect not only improves project outcomes but also fosters a sense of pride and ownership among team members. When Architects raise the bar, they create an environment where excellence becomes the norm, and innovation isn't just encouraged; it's expected. That's how real change happens.

To raise the bar, you need to step up your game.

Commit to Continuous Learning. Dive into new skills, trends, and technologies. Stay curious and surround yourself with more brilliant people; it's your secret weapon.
Define what Excellence looks like. Don't settle for mediocrity. Don't just aim for the finish line; raise it! Push for ~~premium~~ quality in every project and inspire your team to follow suit.
Be Resilient. Understand that raising the bar often involves challenges and setbacks. Stay committed to your goals and learn from any failures along the way.

An Anecdote

There we were—stuck in the same cycle, recycling the same ideas, stuck in old ways of thinking. I could almost feel the office air getting stale with every "tried and tested" approach we threw on the table. We'd become experts at staying within our bubble, convinced there was no better way to do things.

My mind was already wandering to hire fresh blood to shake things up when a curious email popped up in my inbox. Not the usual work one but on my personal account, with the subject: "Internship Inquiry."

The message was from a young, freshly graduated lady who'd found our company because we were one of the few working with this particular technology she was interested in. She went the extra mile, did her homework, read the whole company's website, checked out the team, stumbled upon my name, took a shot in the dark, guessed my email address, and sent it.

Her message was sharp, straight to the point, no fluff, no "I'm passionate about that tech" clichés and had just the right amount of boldness to make me pause.

Intrigued, I replied. We set up an interview. She was brilliant, with a contagious energy, fresh perspectives, and the audacity to ask questions the team hadn't even thought of. Within five minutes, I knew I was hiring her.

And let me tell you, the impact was instant. She breathed new life into the team. Suddenly, everyone was engaged, conversations got interesting, and ideas were bouncing off the walls like they'd been waiting to be let loose. Productivity spiked. Even our most sceptical team members couldn't deny her effect on the place.

It's funny – we spent months circling the same drain, but all it took was one new perspective to shake things up.
The bar was raised just by daring to bring in someone who thought differently and inspired the rest of us to do the same.
And all because someone took a chance on a hunch and sent an email. Sometimes, the best ideas don't come from the usual places; they just need a little nudge… and the right address.

Final Thoughts

Final thoughts? If you're here, you already know that being an Architect isn't just about fancy titles or technical prowess; it's about embracing a mindset that pushes boundaries and builds bridges.

It's about listening more than talking, seeing the whole picture, fostering alignment, driving change, and, yes, constantly raising the bar.

If you're reading this, maybe you're already part of this journey or considering joining it.

Either way, remember: there's no perfect blueprint. Every system, team, and project is unique, and every Architect's path is shaped by their own story.

So stay curious, stay resilient, and keep challenging both yourself and your team. Because when you lead with purpose and vision, Architecture isn't just a role—it's a heritage that leaves an impact.

If you liked this post, follow me on my blog for more.

https://blog.hatemzidi.com/2021/09/19/lessons-learned-from-other-professions/#conductors--maestros ↩
Single Page Application ↩
https://en.wikipedia.org/wiki/Butterfly_effect ↩

Am I a Senior or an Obsolete Architect?

Hatem Zidi — Wed, 21 Aug 2024 08:00:49 +0000

As I am in my late 40ies, I'll be closing my 25th year as an IT engineer this year and my 20th year as an architect.

As I was reflecting on the journey, I wondered: Am I really a Senior or just a Vintage, a Relic?

We often tend to think that a person with considerable years of experience is usually a respected Senior (as a rank and age), but Experience in some careers is viewed as universally positive, but that's not necessarily the case in tech.

In other careers, the craft matures. It becomes less technical and more artistic, and people gain more knowledge while effortlessly getting things done.

Lawyers and doctors are respected when they cross into their 50’s. They are held in high esteem. Tech workers don’t collectively share the same belief.

In our case, the rapid change in technologies and tools, plus the weird label that stuck to us as technology handlers, are making us prone to being obsolete in a few years, if not months.

Anyway, what does Seniority mean?

During my early years, I was convinced that seniority in IT and architecture boiled down to three things:

Competence,
Autonomy,
and Reliability.

Competence was the obvious one—if you’re good at your craft, you’re respected. Autonomy meant you could handle tasks without someone constantly looking over your shoulder, and Reliability was about consistently delivering quality work.

I thought these were the pillars that defined a senior professional. But as I gained experience, I realized seniority is more nuanced.

How Seniority is measured?

But how do companies measure seniority? Is it just the number of years you’ve clocked in, the size of the organization you’ve worked for, or the standards they uphold? Maybe it’s about the technology stack you’ve mastered.

The truth is, there’s no clear answer. Companies often use a mix of these factors, but what really sets senior professionals apart goes beyond technical skills or tenure.

For starters, organisations tend to to say it's about what you’ve accomplished. Have you led critical projects to success? Have you made a tangible impact on the company’s goals? Did you deliver ~~before~~ time?

Then there’s the speed at which you respond, how quickly you respond, and whether you provide effective solutions when problems arise, which demonstrate your experience under pressure.

And speaking of pressure, there's also your ability to handle pressure is another key factor. Seniority often means being the go-to person when the heat is on, someone who can maintain composure and guide the team through tough situations.

But is it really that ?

What I think about Seniority?

Survival is the default mode to be/stay a Senior

Seniority is about more than experience and performance. Seniority assumes that you are a Survivor who copes well with difficulties and works with grace.

It’s about continuous personal development—growing not just as a technologist but also as a leader, a mentor, and a human being.

It’s the commitment to lifelong learning, knowing that the tech landscape evolves continuously.

It’s the frequent self-questioning, wondering if you’ve truly mastered your craft or if you are becoming obsolete.

And Ultimately, It’s about preserving your mental health in an industry that demands relentless energy and often pushes you to the brink of exhaustion especially when you add to that your personal responsibilities.

"No matter your seniority, learn like a junior."

-- Maruffi

But what really defines the Seniority of an Architect?

- How do you steer focus?
- how do you establish the pace?
- how do you preserve integrity & self-awareness?
- how to be a good respected role model?
- how do you take responsibility?
- how do you empower critical and lateral thinking?

But in fact, seniority is more about the intangible qualities that are hidden between the lines of a resume. Some call them Soft Skills, others Leadership or personality traits.

It’s about how you steer focus—not just for yourself but for your team. It's about removing distractions and shifting priorities. A senior professional knows how to keep everyone aligned on what truly matters, cutting through the noise and simplifying complexities to drive results.

As a maestro, it's about how you establish the tempo. The pace at which you work sets the rhythm for those around you. Are you a micromanager? are you pushing hard when it’s needed and easing off when it’s time to reflect? How far are you balancing urgency with patience?

Additionally, Integrity and self-awareness are equally crucial. Senior professionals are usually the moral compass of their peers, holding themselves and others to high ethical/technical standards. They are able to recognize their own strengths and weaknesses, not just as technical experts but as human beings. This self-awareness fosters trust, making you a respected role model who leads by example, rather than just by title.

Furthermore, seniority involves empowering critical and lateral thinking. It’s not just about solving problems but also about encouraging others to approach challenges from different angles.

As a senior, you’re expected to nurture an environment where innovative ideas flourish, and where questioning the status quo is not only accepted but encouraged. This involves mentoring others, sharing your knowledge generously, and praising a culture of continuous learning.

How to not get trapped as a Vintage Architect?

Being “vintage” in the tech world is a bit like being an antique—old, yet still cool if you play your cards right.

It’s about having seasoned experience, but the cultural gap between older tech workers and their younger teams can be significant. Where one person is busy juggling family life, the other might be planning a weekend hicking in the nature. These differences in life stages often translate into different behaviors, interests, and ways of approaching work.

Some older employees struggle to adapt, showing rigidity in the face of change and stubbornness when confronted with new ideas or technologies.

Instead of leveraging their experience to guide and mentor, they resist the very innovations that could keep them relevant. This resistance can lead to isolation within teams that thrive on collaboration and flexibility.

To avoid getting trapped as a ~~obsolete~~ vintage architect:

Stay adaptable and curious.
Embrace continuous learning by exploring new technologies, frameworks, and methodologies.
Engage with your younger colleagues, and be open to their perspectives, this keeps you connected and relevant.
Be patient!
Don’t shy away from change, even if it feels uncomfortable.
Finally, focus on mentoring and sharing your knowledge while being receptive to new ideas. This balance between experience and adaptability will keep you in the game.

Final Thoughts

In essence, seniority isn’t just a title or a reflection of years spent in the industry. It’s about the wisdom you’ve accumulated, how you use it to guide others, and how you cultivate an environment where both the individual and the team can thrive.

It’s not just about being technically brilliant, but also about leading with integrity and the ability to influence without authority.

Seniority isn’t just about what you know or how well you perform; it’s about enduring the journey, staying resilient, and never losing sight of your passion and purpose despite the challenges.

If you liked this post, please follow me on my blog for more.

Lessons learned as/to be a software architect

Hatem Zidi — Thu, 18 Jul 2024 12:11:39 +0000

The role of the software architect is yet a subject of various debate: it's vaguely determined, hard to define and sometime misleads to nonsense responsibilities in some job descriptions.

I won't discuss here about what is the precise day-to-day job of an architect inside a team or a company, but I will try, through my experience, to describe some of the aspects and the qualities that any architect should have.

Many of us think that we are the main person or the hero of a team/company that holds the design or that solves the hiccups throughout a project's live. Definitely, we are not movie stars nor gurus, but certainly we are change catalysts by guiding, enabling and moving people.

Architects are skilled craftsmen

Skill as in the ability to use a specific set of knowledge to relate to a specific context.

It is a large definition depending on how the functional/organizational/business/enterprise/marketing or technical field is.

I don't think, however, that an architect must have or pass multiple exams and certifications to master all these fields, but I assume that when facing any new challenge, he has to be the referring point to drive the team and the [technical] vision of any project.

You may know that creating software architecture is not a process we may plan ahead of time, it's about how you employ your skills and experiences to guide a process with some accuracy.
Though, as I often say:

your smartness is about the way you are hitting on the solution, not the solution itself.

Spot that the solutions made for a project aren't necessarily an applicable artifact for another, but the effort that went into making those solutions and the experience gained can be seen as a skill that can be reused and seen as an asset.

Unquestionably, architects have to be logical, methodical and organized. They have to be passionate, self-disciplined with a mindset of achievement.

Architects are storytellers

Alistair Cockburn said once :

“At its core, software development is people inventing and communicating, solving a problem that they do not fully understand, which keeps changing underneath them, creating a solution that they do not fully understand, which also keeps changing underneath them, and expressing their thoughts in artificial and limited languages that they do not fully understand and that also keep changing underneath them, to an interpreter that is unforgiving of error, where every choice has economic consequences, and resources are limited. Software development is a resource-limited, goal-directed, cooperative game, whose moves consist of invention and communication.”

-- The end of software engineering and the start of economic-cooperative gaming, 2004

To rephrase his quote, let's say that an architect must be a great interpreter, He must be available every day:

discussing with stakeholders in order to understand the real needs,
talking with the managers to notify and alert about the risks and how to avoid them,
and finally, understanding and driving the teams by giving them the vision, the keys and the responsibility of what will be build and delivered.

Architects must be storytellers: they must share enthusiasm, engage and excite their audience, able to explain complex concepts and topics using simple explanation and particularly build a relationship through their story.

However, semantics are essentials. Depending to the audience, the jargon has to be to adapted and be comprehensible; as an architect you have to rule out any misleading understanding and support a clean vision and ideas.

Thus, dealing with people and being a hub between multiple teams or levels means in multiple ways to know how to manage conflicts.

Conflicts are usually issued from insecurities (or often from ego) which are often unsaid, kept hidden and they are extremely contagious.

As an architect you have to be a good observer to identify such problems and empathize with them in a very non-threatening manner, and usually in private.

Architects are doubtful artists

It is tempting to think that the goal of the software architecture is only to build an intricate yet adequate diagram of components with relations among each other or to choose what tools and impose the patterns to implement. And also that the completeness of the architecture is somehow measured in terms of how the architectural artifacts of the system look.

Sorry to say, but this is the narrow view of what architecture is.

Architecture is about understanding the requirement, the propose and the goal of the system, its added value, benefits, complexity and sustainability.

Notice that any implementation is a technical answer to a precise requirement, and we all know that we can't be certain about our choices without being aware about what are the final result.

As a rule, before any design process, you need to take a step back in your mind and see the design in full function. This has to be done before any cardboard mock-ups or prototypes are built, and the process should be revisited at every major change point during the life of the project.

The architect has to mimic the user and see himself using the system.

Albeit that the end user is not the goal but his expectations are, the fulfilment of this goal is the real reason for which a system will be built.

The better the architect is at seeing this, the better he will be at understanding what needs to be put or implemented.

I believe that art is a big part of software architecture, and that is the ability to visualize a product ahead of time, to feel it or envision it as a whole large solid system in a quite rich detail. It's not only about skills and experience but more about experimentation, creativity, awareness and adoption.

As an architect, you must have a good imagination and be good at painting mental pictures.

This skill may be taught, but aptitude for this activity is critical. Experience builds it, too.

By having this mental picture in your head, the real design process will be more accurate and elegant, which does not end until the project ends.

Architects are negotiators

Undoublty, any project is always an acknowledgement to a customer's purpose, and often the latter himself is the main provider of the trickiest parts of the project: the constraints and the users.

A software is always a tool that any end user needs to simplify and/or eliminate constraints in an activity or a workflow, and often to accelerate the gears by decreasing the latencies.

Usually what's obvious and trivial to a customer/end user may mean ~~more~~ hidden constraints and extra work, thus costs for the project.

In fact, depending of the size of a project, there are several other roles as the business analyst function that can handle much of the work of requirements gathering. Even though an architect might not have to be personally involved in requirements gathering, but no matter what the final specifications are, the architect always needs to comprehend and feel what the end user really needs.

Remark that for any expressed requirements, end users don’t understand technology and developers don’t understand people! Hence this is one of the problem that needs to be smartly bridged.

Understanding the needs, making and trading choices, negotiating about eliminating or delaying a request, bargaining about using a technical solution or pattern are the day-to-day tasks of the architect.

As an architect you have to be good negotiator, with a large visibility on the project's goals and at the same time being details oriented to drive correctly the project.

However, Architects don't have to be talented psychologists, but you have to feel how the winds blow in an organization (customer, managers, stockholders, team), especially if the winds are not just gentle breezes.

I think that is a fundamental mistake to not listen to the organization when creating architecture.

Architects are decisions makers

I believe that any architect constructs the architecture of the solution in a manner that enables developers to use their tools effectively.

He enforces high standards and makes sure that work on the project is as enjoyable, straightforward and efficient as possible.

Yet it's not only about the implementation, but about the best practices and the best tools to use to deliver the project.
It's not about the wide-ego and guru-attitude, but about decision making and the choices to make that fit to the requirement.

this being said, Uncle Bob said :

Good architecture allows major architectural decisions to be deferred. The job of an architect is not to make decisions, but to defer decisions as long as possible, to allow the program to be built in the absence of decisions so that decisions can be made later with the most possible information.

Gregor Hohpe rephrases this in his book The sofware architecture elevator by saying:

[...] Architects are commonly described as the people dealing with nonfonctionnal requirements ... they deal with nonrequirements.
Architecture isn't good or bad, it's fit or unfit for a purpose.

Obviously, Decision is about the context, the trade-offs, the choices, the possibilities and finally the proof.

Hence, A software architect is always labelled as the flame keeper who owns the principles of the project: He don't let stress get the better of him, he assesses the goals and the values, he evaluated the choices and rethink about them.

He must be a stickler for detail and an enforcer of high standards, while always having the guts to make critical changes to a design when necessary.

Architects are agile wizards

First, let's assert that:

Adaptability is mostly centred around considering all possible options, identifying opportunities and devising a plan, whereas agility is more about having the confidence to take swift and decisive action in the face of unexpected change.

Admittedly, one of the main purpose, and the most valuable one, of the Agile Methods is to deal with the uncertainty like uncomplete/hidden requirements or any potential risks.

Moreover, architecture is a journey on an unknown road where we spend most of our time dodging speed bumps and potholes. Architects must provide systems that can evolve alongside with the increasing understanding of the needs and the technology.

Proposing or setting boxed-monolithic-tightly-coupled software or code can't help you if you have to steer out of a pothole, in fact it's a nightmare scenario.
Any system that can't be touched, that can't evolve or changed and has no agility at all is by definition an isolated legacy system.

The value of an architecture increases with its ability to change and insure the sustainability of a system.

Event though, most of architects may adopt "Fail fast, Learn fast" but that has more impact of the overall quality, however reacting quickly and prioritizing changes make your system sustainable by achieving and following the suitable architectural patterns ...

Architects are influencers and impact makers

As stated above, the role of an architect is not limited to be labelled as a technical wizard, his interaction with his peers inside and outside a project may forces him also to push the limits, to improve the global moral and to steer the global vibes.

Furthermore, architects have to break the ground with new ideas, outspread new concepts, and derive new proposals. Additionally, by taking time to be out of their comfort zone, they'll generate more opportunities and may inspire their peers

Likewise, by updating their colleagues about the progress and sharing their knowledge, they engage them to share and collaborate with each others.

Architects have to deliver also a high quality work and be sure that they can be trusted by sharing their skills, oversight and good solutions, they have to be the person other people count on by offering help, patience and understanding. He's the model to follow and to refer to for his proven sense of leadership.

Additionally, architects have to speak up, share, state and defend their opinions by being opinion leaders but also they have to be great listeners and empathetic.

and obviously, Architects are agnostic

Being technology-agnostic prop up that there is no ‘one size fits all’ for a particular problem, there are many ways to solve it.
It means also that a decision to use or not a technology/component/solution/pattern is an educated decision based on wisdom and experience.

Ordinarily, the architect position is (one of) the natural evolution of a ~~skilled~~ developer, but being an architect you have to remind yourself that "technology is a tool", it may be leverageable or disposable.

You have to focus on the big picture and understand the limitations of any (to be) proposed solution according to the customer's constraints and requirements, it's not just choosing the cheapest solution that your are most familiar with.

Similarly, you have to be flexible, open minded and self confident to dive into a huge spectrum of tools, solutions and brands across the market. The architect's maturity is by avoiding vendors lock-in, high dependencies and insuring to accommodate the architecture and cost-save the project without making expensive modifications.

Generally speaking, it's about the good toys for the good purpose.

Closing

Despite the fact that I wrote the first draft of this post some 8 years ago, this updated version summarizes multiple thoughts, experiences, readings and findings. I'm sure there is lot of missing here, but I chose to not go deep in the low-level/day-to-day details but share the most common qualities that a software architect must have.

Let's not forget that the customer wants to efficiently and preferably enjoyably use his software, the software architect has to focus on realizing this and keep the goals clear.

It's not an easy job, but we have to measure our value in our ability to understand the hidden requirements and the trade-off, to look and foresee beyond the product and being articulate while delivering a high quality package.

If you liked this post, follow me on my blog for more.