Architecture: what versus how
Requirements say what must be true. Architecture says which pieces will be responsible — and how they are allowed to lean on each other.
- You can separate a functional view (what must happen) from a physical view (what will do it), and allocate one to the other.
- You know why an architecture diagram without its rejected alternatives is decoration.
Architecture is the set of decisions that are expensive to reverse: what the major elements are, what each is responsible for, and how they interact. Everything else is design, and design should stay cheap to change.
The useful discipline is to hold two pictures at once. The functional architecture describes behavior in verbs — capture, validate, decide, notify — with no technology in it. The physical architecture assigns those verbs to real elements: services, databases, devices, people. The mapping between them is where most architecture arguments actually happen.
3.1Decompose on responsibility, not on org chart
The default decomposition in most organizations is the team structure, which is why systems end up shaped like meetings. Conway's Law is descriptive, not a law of physics: your architecture will mirror your communication structure unless you deliberately choose otherwise.
Good boundaries have three properties:
- High cohesion — everything that changes together lives together. Pricing rules and pricing data in the same element.
- Loose coupling — an element can change without forcing coordinated releases in three others.
- Clear ownership — one name is accountable for each element's behavior, including its failure behavior.
Where you put a boundary is a trade, and trades come with consequences. Here is the same decision made three ways for a "risk scoring" capability.
Inside the monolith — fastest to build and debug, one deploy, no network contract; but scaling and failure are shared with everything else.
There is a real cost to over-architecting, and it is easier to spot in hindsight: three layers of abstraction before the first user, an interface catalogue for a system with one consumer, a "platform" that is a wrapper around a database. The test is not "is this well structured?" but "does this decision buy me the ability to change something expensive later?" If it doesn't, it is design, and design should be cheap enough to throw away.
3.2Record the decision, not just the diagram
A diagram shows the current state. It does not show why, what was rejected, or what would have to be true to change it. That is what an architecture decision record is for, and it can be six lines:
# ADR-014 — Scoring runs as a separate service
Status: accepted 2026-03-11
Context: scoring changes weekly, the monolith ships daily; p95 budget 300 ms
Decision: extract scoring behind an HTTP contract, owned by the risk team
Rejected: in-monolith (blocks weekly change cadence); vendor API (data residency)
Revisit: if call volume drops below 1k/day, fold it back inSix lines like that, written when the decision is made, save a hundred messages eighteen months later. The "revisit" line is the one people forget — and the one that keeps an architecture honest.
3.3The views that earn their maintenance
| View | Answers | Audience |
|---|---|---|
| Context / boundary | What is inside, what do we design against? | Everyone, including sponsors |
| Functional flow | What happens, in what order, with what inputs? | Engineers, testers, ops |
| Allocation | Which element owns which function? | Teams, on-call, security review |
| Interface catalogue | What crosses each boundary, in what format? | Integrators, testers |
| Deployment / runtime | What actually runs where, and how it fails over? | Ops, SRE, incident response |
Draw the ones you will keep current. Four accurate views beat twelve stale ones, and a stale diagram is actively harmful — people make decisions from it.
If the only artefact is an image in a slide deck, the architecture is whatever the code did last sprint. Keep the decisions in text, versioned next to the code, and delete diagrams you no longer maintain. The test of an architecture document is whether a new engineer can answer "why is this like this?" without asking a person.
What makes an architecture decision record useful eighteen months later?
60-second recap
- Requirements are what; architecture is which elements own it. Keep the two views separate and allocate explicitly.
- Decompose on cohesion, coupling and ownership — not on the org chart.
- Every boundary is a trade. Write down the alternatives you rejected.
- Maintain fewer views, but keep them true. A stale diagram is worse than none.