The most consequential misunderstanding about enterprise architecture is that its primary output is documents. Architecture diagrams. Standards frameworks. Repository entries. Governance artefacts. This misunderstanding is so common that it has become the default mental model — and it explains most EA failures.
The primary output of an architecture practice is alignment. The documents are instruments for producing it.
What communication means in practice
An architecture practice creates shared understanding across the four structural boundaries described in the previous article — organisational diversity, IT complexity, mismatched planning horizons, and absent shared vocabulary. It does this through artefacts that make complex planning decisions legible to diverse stakeholders, through processes that ensure the right people are involved at the right moments, and through governance that makes decisions official and auditable.
Every element serves this communicative function or it serves nothing. An architecture diagram that nobody reads has not contributed to alignment. A Standards document that project teams are unaware of has not improved technical coherence. A governance committee that endorses documents without genuine review has not created legitimate organisational commitment.
The diagnostic test: Examine an architecture repository. If it is comprehensive, well-organised, and not referred to in planning meetings, the practice is a documentation exercise. Ask whether IT investments are being made differently because of architecture work. If the honest answer is no, the practice has not yet found its communicative purpose.
The development process is more valuable than the document
This is one of the most important empirical findings about how successful EA practices actually work. The conversations that produce a Business Vision or a Business Outline are where alignment is achieved. The finished artefact documents agreement already reached — it is not the mechanism through which the agreement is formed.
An architect who works alone, produces a technically excellent document, and presents it to stakeholders for approval is not practising architecture in any meaningful sense. They are producing a personal view of what the architecture should be. The stakeholders may endorse it — under time pressure, with incomplete understanding, without genuine ownership. The document will then sit in a repository and be ignored during actual decision-making, because nobody except the architect who wrote it feels accountable for it.
Genuine architecture artefacts emerge from the D-E-A process: conversations first, document second, formal endorsement last. The D-E-A pattern is described in Article 6. Its significance here is that it positions communication — not documentation — as the primary activity of architecture work.
Implications for how practices are organised and evaluated
If architecture is fundamentally a communication practice, several things follow that contradict how most architecture teams are structured.
The most valuable thing an architecture function can do is cultivate trusted relationships with senior business leaders. Not produce architecture artefacts. Not maintain the repository. Not enforce governance compliance. Relationships — because relationships are what make the conversations possible through which alignment is actually achieved.
The most important skill an architect can develop is the ability to translate between business thinking and technical thinking in both directions simultaneously. Not technical depth alone, and not interpersonal skill alone. Both, simultaneously, in the same conversations. This is developed in Article 15's treatment of the two hats every architect wears.
Maturity is measured not by artefact coverage or governance completeness but by whether business leaders understand what IT is doing and why. This is the subject of Article 19's five-question maturity test.
What this means for AMBIT
Every element of AMBIT is designed with this communicative purpose in mind. The Alignment Matrix classifies artefacts by their audience and the type of understanding they are meant to produce. The three Alignment Processes are structured around the conversations through which different types of decisions get made. The governance forums exist not to make decisions but to make decisions official — because genuine decisions already made through conversation need organisational authority to be binding.
The framework does not succeed when an organisation has produced all six artefact types and established all four governance forums. It succeeds when business leaders and IT professionals understand each other — when IT investment consistently reflects business direction and business leadership understands how IT is transforming their organisation. Artefacts and governance are the means. That mutual understanding is the end.