Enterprise architecture has a reputation problem that the discipline's practitioners have largely earned. EA programmes that produced elaborate current-state and target-state architectures, multi-year transformation roadmaps, and governance gates that delivery teams routed around. The output was sophisticated, internally consistent, and disconnected from how the organisation actually built systems. The reputation problem is fair where it applies; it does not apply to every EA programme. The implementations that produce value share characteristics that templated EA programmes lack, and the difference is mostly operational discipline.
EA That Shapes Delivery vs EA That Documents Decisions
The most useful test of an EA programme is whether architectural decisions actually shape what delivery teams build. EA that shapes delivery operates with continuous engagement — architects embedded in teams or rotating across them, decisions made with delivery teams rather than handed to them, standards developed jointly with the engineers who will follow them. EA that documents decisions operates with formal governance — review boards, approval gates, comprehensive documentation produced before delivery starts. The first model is harder to staff but produces architectural influence. The second model is easier to scale but is routinely worked around.
The Right Use of TOGAF
TOGAF as a methodology has substantial intellectual content — the Architecture Development Method (ADM), the architecture content framework, the enterprise continuum. Used selectively, the concepts are useful as shared vocabulary and as structured thinking aids. Used as a comprehensive process that an EA programme must perform end-to-end on every initiative, TOGAF produces overhead that consumes the programme's capacity. Most successful EA practices use TOGAF as a reference rather than as a mandate, applying its concepts where they add value and skipping the ceremony where they do not.
Architecture Decisions Worth Capturing
A useful EA programme captures decisions that have lasting consequences — patterns for identity and access, data architecture choices, integration approaches, technology platform selections, regional or regulatory boundaries. These decisions affect what delivery teams build for years; capturing them deliberately makes future change easier. Decisions that do not have lasting consequences — specific library choices, single-project trade-offs — should not be in the EA artefact set. Documentation that captures everything captures nothing usefully.
A trap that catches EA programmes: investing heavily in current-state architecture documentation, finishing it eighteen months later, and discovering it is now twelve months out of date. The current state is moving faster than the documentation. The pragmatic alternative is documenting current state at the depth that supports specific decisions rather than aiming for comprehensive coverage. EA artefacts that are produced in service of a decision tend to be relevant; artefacts produced as inventory tend to age out before they are used.
Capabilities and the Business-IT Alignment Problem
Business capability modelling is one of EA's genuinely useful contributions when done carefully. A capability map describes what the business does at a level of abstraction that survives organisational restructuring and technology change. Capabilities map to systems, processes, and data — providing a coherent way to discuss whether IT investment supports strategic priorities. The map only works if it is built thoughtfully (capabilities phrased as outcomes, not as departments) and used actively (revisited during strategy and portfolio discussions, not produced once and filed). EA programmes that produce capability maps without operational use derive limited value from them.
How to Run an EA Programme That Earns Its Cost
- Embed architects in delivery rather than operating an isolated EA function
- Capture decisions through lightweight ADRs rather than comprehensive documentation
- Use TOGAF and Zachman as concepts and vocabulary; skip the ceremony
- Build a capability map and actually use it — strategy reviews, portfolio decisions, investment discussions
- Maintain a small set of architecture standards and patterns that delivery teams adopt voluntarily
- Measure the programme by influence on delivery, not by artefacts produced