Writing 9 min read
The evolution of the software architect: from builder to system designer
Twenty years ago the job was to draw the diagrams. It is now to frame the decisions, and the title has not caught up. What the architect elevator leaves out is what the ride costs to keep.
The first time I was called a software architect, the job was to draw box diagrams.
This was the mid-2000s. The role was well-defined in the consultant playbook of the era: you were the person who produced the UML, picked the design patterns, chose between WCF and REST, and wrote the standards document that the development team was supposed to follow. Your deliverable was a folder of Visio files no one really paid any attention to, and some documents with the word “framework” in the titles.
I did this job for several years. I did not particularly enjoy all of it. The parts I found interesting — the conversations with the business, the architectural nuances and choices, the trade-off and priority reasoning, the political negotiation about what should be built and why — were not officially part of the role. They were side effects but the essence of it too. The deliverables did not really matter that much even when the role, as written, was about producing the diagrams, because someone somewhere is footing an expensive bill. Everything else was tolerated as long as you kept producing the diagrams. But it was probably the other way around.
Twenty years later, the role has changed in ways that the title has not caught up with. The diagrams still exist somewhere, but they are no longer the job. The new job is something else, and it is worth being explicit about what.
What the old role was actually optimizing for
The builder-architect of the 2000s and early 2010s was optimizing for something real: reducing variance in large codebases (aka chaos and drift and mud). In a world where dozens or even hundreds of developers of varying skill levels were working on the same system, and where the cost of a bad abstraction was measured - and not that often - in years of maintenance, the architect’s job was to impose structure from above, even when misguided or too constrained. You picked the patterns, often in advance and with little information, applying recipes and muscle memory from past engagements, and wins and defeats. You wrote the standards. You enforced the conventions. The goal was not to make the codebase brilliant; it was to make the codebase as consistent as possible, because some degree of consistency was the only way to keep a large team from producing a mess. Even when it was largely an uphill battle in the face of constant pressure to deliver more faster and cut whatever corners in the process.
This worked, mostly, in varying degrees, for the problems of its time. It produced legible enterprise systems and did not prevent showcase textbook failures. It gave junior developers a scaffolding to work inside (some constraint and structure is actually liberating). It kept the variance down. It was necessary.
It was also deeply, structurally conservative. The architect’s role was to reduce risk, and reducing risk meant saying no to most new ideas. The failure mode of the builder-architect was not a bad system — it was a system that could not change, because every change had to pass through the architect’s filter, and the filter got narrower with every year of service. By the mid-2010s, the term “architect” had become mildly derogatory in many engineering circles, as well as on the business side of the divide. It meant the person who was slowing you down. Some organizations kept these weird folk around, in their particular ivory tower, a relic from the past they did not dare tear down for fear some obscure function would cease working and something ignote would break. Or just out of inertia or reputation.
That was not the architect’s fault. It was the role’s fault. The role was designed to produce conservatism, and conservatism is what it produced.
What the new role is optimizing for
The system-designer architect is optimizing for something different: making good decisions at the seams. Not inside individual systems, which modern tooling and modern teams can usually handle on their own, but at the seams where systems, teams, products, and strategies meet and have to agree on something.
The work has moved outward, in two directions.
Outward into the business. The modern architect spends meaningful time with product leaders, business heads, finance people, and occasionally the board. Not because they have become executives — most of them are still hands-on technically — but because the decisions that matter for the architecture are increasingly decisions about what the business is trying to do, and those decisions are not made in the engineering org.
Outward into the seams. Between cloud and on-premise. Between platforms and products. Between ML and distributed systems. Between vendors and in-house. Between the architecture you inherited and the architecture the new demands that AI features want. These are the places no single specialist can own, which is exactly why the interesting problems live there.
The old architect produced diagrams of systems, largely self-contained with little or no outside calls and dependencies. The new architect’s deliverable is not a static Visio file anymore. It is a crisp, defensible, live set of documented decisions with their assumptions written down, reversibility classified, optionality built-in and its implications explained to the people who need to understand them in a language that they understand (this has not really changed since then and communication is still key).
Gregor Hohpe named this movement better than I will. His architect elevator rides between the penthouse and the engine room because the people on each floor cannot hear each other, and somebody has to carry the message without it turning into the telephone game. That destination has been described. What is missing is what the ride costs, and what happens when the building is not a skyscraper.
Three things the elevator does not tell you
Standing decays. The elevator assumes you are allowed on it. Credibility on the engine-room floor is not a title, it is recent evidence, and it has a half-life. An architect who has not shipped anything in four years is visiting, not riding, and everyone on that floor can tell inside ten minutes. The decay is invisible from the penthouse, where the same architect still sounds authoritative, which is how you end up with someone who has lost one of their two floors and does not know it.
Most buildings have three floors, not thirty. Hohpe’s frame is the large enterprise and he says so: a skyscraper so tall that one elevator might not span it. Half the companies I work with have forty people. The CTO is in the engine room and in front of the board the same morning. There is no distance to cover, so the skill is not travel at all. It is holding both altitudes at once, in one conversation, without changing register when the founder walks past. The enterprise literature barely names that, because the enterprise never has to do it.
Increasingly, the architect is not an employee. The elevator is internal: it presumes a badge, a reporting line, and a building you belong to. The advisory architect has none of that. You do not ride, you are invited to a floor, once, and you get one meeting to establish that you belong on it. Nothing accrues between engagements. That entry cost is the largest hidden expense in the model, for you and for the client paying you to spend two weeks earning the right to be listened to.
The skills that matter now
Four things, and the fourth is what makes the other three count for anything.
Framing. The ability to take a vague, tangled, multi-stakeholder question and reformulate it as a specific decision with named options and named tradeoffs. This is the single hardest skill in the new role and the one that most differentiates senior architects from junior ones. A staff engineer can answer a well-framed question. A principal architect reformulates the question so that it can be answered at all.
Translation. The ability to move fluently between the vocabulary of engineers, product managers, executives, and business stakeholders — and, critically, to do it in real time, in the same conversation, without code-switching awkwardly. The architect’s job now includes explaining to a CEO why a particular architectural decision can affect a critical process, some competitive advantage or the bottom line down the line in eighteen months, and doing it in language the CEO can act on. And to do this without sounding ominous or pessimistic, even when the point might be somber and still needs to be driven home. This is human work, translation work, not technical work, and it is where most senior architects are undertrained, and scars can only be gained in the battle field.
Judgment about reversibility. The architect’s most valuable output is knowing how permanent each decision is, and making sure the team treats it with the right weights in mind. This is not glamorous but rugged. It is also most of the job. Context, nuance, long-term vision, Wardley Maps and other tools, you have to hold in mind much more than others do, can or are even willing to, in their narrower tactical domains.
Having to live with it. Everything above describes producing decisions, and the obvious objection is that anyone can write a memo. Hohpe calls the failure mode authority without responsibility, and it breaks only when the architect has to live with the consequences, or at least stay close enough to watch them land. An architect who frames a decision, documents it, hands it over and leaves before the bill arrives has made a recommendation, not a decision, and a recommendation is a cheaper thing. The distinction is not moral but epistemic: you do not find out whether your judgment was any good unless you are still there when the system tells you.
Notice what is not on this list. Pattern catalogs. UML. Framework design guidelines. These are not irrelevant — they are still part of the toolkit — but they are not where senior architects spend most of their time anymore. They are table stakes, not differentiators.
The personal part
I will be honest: the shift in the role has been good for me, because the parts of the job I always found interesting — the framing, the negotiations, the cross-domain mediations — are now the parts the role is measured on. The parts I found less creative with time, once the novelty of the junior architect wears off — the diagrams, the standards documents, the governance reviews — have become less central. I do not miss them.
But major shifts are rarely kind to everyone. Architects who built their careers around being the person who boasted the technical prowess, who knew the most patterns, or the person who had the purview to write and enforce the standards, or the person who produced the best diagrams, have found themselves in a role they did not sign up for. The role asks for skills they were never hired for or developed. Some of them have adapted. Some of them perhaps have not that well.
The ones who adapted did so by doing a specific thing: they stopped thinking of themselves as builders of systems and started thinking of themselves as designers of decisions, expert guides in a complicated landmined terrain no one has the entire map to. Once that reframe lands, the rest is learnable. Before it lands, the new role feels like an imposition to redefine our identity. After it lands, the old role feels like an old cage.
The last ten things you made
If you are a software architect wondering whether your role is heading somewhere you want to go, try this: look at the last ten things you produced that were genuinely useful to your organization. How many of them were diagrams? How many of them were documented decisions with framing, tradeoffs, and implications, ADRs perhaps? How many were actually not that tangible even?
If most of them were diagrams, you are still doing the old job. That is fine, and it is sometimes still the right job — but it is not where the senior work is going. If most of them were documented decisions, you are doing the new job, whether your title has caught up or not. The title will eventually catch up. The work is what you defend.
And then ask the harder one, which is the fourth skill wearing everyday clothes: how many of those ten did you stay to see the consequences of?
The architect used to build systems. Now the architect designs the decisions that determine what the systems become. Both are real. Only one is what the role is becoming.