Reference Architecture
Overview
Section titled “Overview”Section 1 produced a decision. A decision sits in one document and governs one initiative; the teams that have to build things make dozens of structural choices a week, and none of them will read your trade-off table.
A reference architecture is how one decision governs many later ones without you being in the room.
What it is, and what it is not
Section titled “What it is, and what it is not”A reference architecture is a prescribed set of structural elements, boundaries and rules for a class of systems in your estate — not the design of one system.
The distinction matters because the two documents have different lifespans and different readers. A design describes what you are building now and is finished when it ships. A reference architecture describes what anything of this kind must look like, and it is never finished.
| Belongs in it | Does not belong in it |
|---|---|
| The components that must exist, and what each is responsible for | The internal design of any one component |
| Where the boundaries are, and what may cross them | Specific libraries and vendors |
| The rules that hold without exception | Anything you cannot give a reason for |
| The defaults a team gets for free by not deciding | Anything that is really just your taste |
That last row on the left is the most undervalued. A reference architecture’s main gift to a team is the decisions they do not have to make.
Constrain without prescribing
Section titled “Constrain without prescribing”The practical technique is to write each rule as a constraint plus its reason, and stop before the implementation.
Prescribing: “Use the managed vector database in the primary region.”
Constraining: “Retrieval must expose the provenance and trust level of every chunk it returns, because content below a stated trust level may never be treated as instruction. Storage choice is the team’s, provided it satisfies this and the residency rule.”
The second version survives a vendor change, gives the team real ownership of something they know more about than you do, and is enforceable in review because it names an observable property. It also does the thing Module 1’s charter was for: it draws the line between what you decide and what you explicitly do not.
The test for every line in the document: can a team satisfy this in a way you did not anticipate? If not, you have written an implementation and called it architecture.
The payoff is a smaller decision budget
Section titled “The payoff is a smaller decision budget”A team shipping a new component inside a good reference architecture makes fewer decisions, and the ones they do make are the ones they are best placed to make. That is a speed gain, not a bureaucratic cost, and it is the argument to use when someone reads the document as red tape.
The secondary payoff is consistency without coordination. Two teams who never speak produce compatible systems, because the compatibility was decided once, upstream. In an organisation with no architecture practice, this is the cheapest coordination mechanism available.
Three ways it dies
Section titled “Three ways it dies”It goes stale. The estate moves, the document does not, and within a year it describes a system nobody is building. Then it is worse than nothing, because following it produces the wrong thing.
It becomes a bottleneck. Every exception needs your approval, you are the single point of failure for a hundred engineers, and teams begin routing around you — which is how you lose the practice rather than the argument.
It ossifies. The rules outlive their reasons. Nobody can say why a rule exists, so nobody can tell when it has stopped being true, and the document becomes a set of superstitions with a version number.
The response to all three is the same mechanism: exceptions are allowed, must be recorded with their reasoning, and the accumulation of exceptions is the signal to revise. Three teams needing the same exception is not three violations; it is a rule that is wrong. Module 9 builds the governance that makes this routine rather than heroic.
The cost of running it this way is honest: it means publicly changing your own document, repeatedly, in front of people who watched you write it. Architects who cannot do that produce reference architectures that everyone ignores politely.
Feeds the workbook
Section titled “Feeds the workbook”This topic feeds the reference architecture sketch — C4 Level 2, showing where the AI components sit relative to the monolith and the Go services. Include the rules that hold without exception and, separately, a short list of what you are leaving open. The second list is what makes it a reference architecture rather than a design.
→ The shape is prescribed. The order it gets built in is a different question, and it has to be made under genuine uncertainty. — Strategy as a sequence of bets