Somewhere in the document management system of almost every organisation where I have done serious architecture work, there is a document — approved, version-controlled, endorsed at the Architecture Review Board — that describes the target architecture for the next five years. It took months to produce. It is technically sound. And it is, for practical purposes, not influencing the day-to-day decisions that are actually determining what gets built.
I have come to believe this is not an aberration. It is the normal condition of enterprise architecture documentation, and pretending otherwise — producing longer documents, holding more review sessions, issuing updated versions with greater frequency — does not change it.
Why Nobody Reads Them
Architecture documents are not read for reasons that are individually banal and collectively important. They are too long. They are written for approval rather than for use. The people who need to act on them — the developers, the solution architects, the project managers making daily decisions — were not involved in producing them and do not feel addressed by them. And they are typically written at a level of abstraction that is authoritative in governance conversations but not directly applicable to the specific decision someone is trying to make on a Tuesday afternoon.
In one programme, I returned after an eighteen-month absence to find the delivery teams building something that diverged significantly from the architecture that had been formally approved before I left. When I asked why, the answers were consistent: nobody had told them the document existed, or they had been told about it but had not seen how it connected to the work they were doing, or they had read the executive summary and found it too abstract to be useful. The document had been approved at every level. It had influenced almost nothing.
An architecture document that is approved but not used is not a governance success. It is a governance theatre — the appearance of alignment without the substance of it.
What Actually Guides Architectural Decisions
In the absence of readable, accessible architectural guidance, decisions get made by other means. By the technology preferences of the most senior engineer in the room. By whatever the last major vendor proposal recommended. By what was done on the last project. By what is familiar. By what can be delivered quickly enough to meet the next milestone. Each of these forces is real, and each operates independently of whatever the architecture document says.
The organisations where architecture actually influences delivery are not, in my experience, the ones with the most comprehensive documentation. They are the ones where the architecture has been communicated — explained, discussed, made tangible through examples and constraints and principles that people can actually apply — to the teams doing the work.
What Documents Are Actually For
Architecture documents have genuine value — but not the value they are usually written to provide. They are valuable as records of decisions made and the reasoning behind them. They are valuable as audit evidence. They are valuable as alignment tools for executive governance conversations. They are not, for the most part, valuable as operational guides for the people making daily technical decisions.
The implication is uncomfortable but important: if your objective is to ensure that the architecture you have designed actually influences what gets built, producing a more thorough document is rarely the right answer. The right answer is usually more direct engagement with the teams that are building — conversations, constraints embedded in tooling and process, architectural principles that are short enough to remember and concrete enough to apply.
The most effective architecture work I have done has not produced long documents. It has produced short principles, clear constraints, direct conversations, and an ongoing presence in the decisions that matter. The documents followed, as records. They did not lead.
If the measure of architectural success is a well-written, well-approved document, you are measuring the wrong thing. The measure is whether the architecture you intended is the architecture that was built.