What Architecture Actually Is
Overview
Section titled “Overview”The module’s question is what is this job, and what am I responsible for here? You can’t answer it without a working definition of architecture — and most definitions in circulation are either too vague to use or quietly wrong.
This topic gives you one you can apply, then separates the three different jobs the word covers.
A definition you can use
Section titled “A definition you can use”Architecture is the set of decisions that are expensive to change later.
That’s it. Everything else is implementation.
The definition is useful because it’s a test rather than a description. Faced with any decision, ask: if we get this wrong and discover it in a year, what does it cost to reverse? If the answer is “an afternoon”, it isn’t architecture, however technical it looks. If the answer is “six months and a migration”, it is — even if it looks like a small choice.
Which database a service uses is probably reversible. Whether customer data may leave a given region is not — it shapes the vendor choice, the deployment topology, and the contracts you can sign. One is a preference. The other is architecture.
What architecture isn’t
Section titled “What architecture isn’t”Three misconceptions, each with a real cost.
It isn’t choosing technology. Technology choice is an output of architecture, near the end. An architect who starts there has skipped the work that would tell them which choice is right. More on this in the next topic.
It isn’t drawing diagrams. A diagram communicates a decision; it isn’t the decision. The test: if someone asks “what did we decide, and why?”, can you answer without pointing at a picture? If not, nothing was decided — something was drawn.
It isn’t being the most senior engineer. The best programmer in the company and the person who should decide cross-team structure are different roles requiring different skills. Conflating them is how companies lose a great engineer and gain a mediocre architect.
Gregor Hohpe’s metaphor for what the job is has stuck because it is accurate: the architect rides the elevator between the penthouse, where strategy and money are discussed, and the engine room, where the work happens. The value is in the travelling. Someone who stays in the penthouse produces strategy nobody can build; someone who never leaves the engine room optimises a system the business has stopped needing. The Software Architect Elevator is the long version, and it is the single most useful book for the parts of this guide that are about the role rather than the systems.
Three architectures, one word
Section titled “Three architectures, one word”graph TD EA["Enterprise<br/>the whole company's technology<br/>3–10 years · answers to executives"] SA["Solution<br/>one initiative, across teams<br/>6 months – 3 years · answers to the sponsor"] SYS["System<br/>one system's internals<br/>now – 18 months · answers to engineering"] EA -->|"sets constraints for"| SA SA -->|"sets constraints for"| SYS SYS -.->|"reality pushes back"| SA SA -.->|"reality pushes back"| EA classDef tier fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff classDef subject fill:#E8A33D,stroke:#C4832A,stroke-width:3px,color:#ffffff classDef low fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff class EA tier class SA subject class SYS low linkStyle 2,3 stroke:#D9695B,stroke-width:2px
The three architectures by scope and time horizon. Constraints flow down; reality flows back up — and the upward arrows are the ones people forget.
Enterprise architecture covers the company’s technology estate as a whole. Which platforms exist at all, whether the company standardises on one cloud, what every team must comply with. Horizon in years, audience executives.
Solution architecture covers one significant initiative, usually spanning several teams. Bounded — there’s a beginning and an end — but wider than any single team. This is the job this guide is about.
System architecture covers the internals of one system: components, how they talk, how they fail. Horizon is the current roadmap. Closest to what a strong tech lead already does.
Where the boundaries actually blur
Section titled “Where the boundaries actually blur”The clean split above is a teaching device. In practice it moves with company size.
At 50 engineers there’s usually no architect. A staff engineer or CTO makes these calls between other work, and all three horizons live in one head.
At 150 the company usually hires its first architect. There’s no enterprise function yet, so a solution architect makes some enterprise-level calls by default. Nobody grants this; it happens because someone has to.
At 500+ the roles genuinely separate and an architecture board exists. The risk inverts: instead of one person covering everything, you get architects so specialised they lose contact with running systems.
What “accountable” means when you have no authority
Section titled “What “accountable” means when you have no authority”In most of these roles you cannot direct a single engineer. So what are you accountable for?
The decision and its reasoning — not the code. If the platform fails because retrieval quality is poor, “the team implemented it badly” isn’t available to you. Evaluating retrieval quality was an architectural concern.
Consequences you didn’t name. Naming a risk that then materialises is a professional success, however uncomfortable. Missing it is not.
Decisions you deliberately don’t make — as long as you said so. “The team chooses the vector store within these constraints” is a decision. Silence is not; it’s an absence someone else fills.
The cost of this framing is that it makes you accountable for things you cannot directly control. That’s not a flaw in the description — it’s the actual condition of the job, and the reason the last third of this guide is about influence rather than technology.
→ You now know what kind of decision is yours. Next: how do you tell a good one from a bad one? — Why the job exists: creating value