Enterprise architecture as a discipline grew up in an era when major IT initiatives lasted multiple years and the cost of architectural mistakes compounded over the same horizon. The artefacts that defined the discipline — comprehensive current and target state architectures, transition roadmaps, formal governance gates — fit that era. They fit modern delivery less well. Most organisations now ship significant capability changes in weeks, not years, and EA functions that operate at the older cadence end up being routed around rather than relied on.
The Tension That Needs Resolving
Agile delivery values working software over comprehensive documentation; emergent design over big up-front planning; rapid iteration over multi-stage governance. Traditional EA values exactly the things agile de-emphasises. The temptation has been to declare one of the two wrong. Both are right within their context. The architectural decisions still matter — wrong choices about identity, data architecture, integration patterns, or capability boundaries are still expensive years later. The agile delivery cadence is also right — markets move faster than any organisation can plan in detail.
What Agile EA Actually Means
Agile enterprise architecture is not a contradiction. It is EA practice rebuilt around three principles. First, architecture decisions are made just-in-time at the point of delivery rather than just-in-case as part of a master plan. Second, architecture work is incremental and continuously refined rather than produced in big up-front documents. Third, architects work alongside delivery teams as collaborators rather than as gatekeepers reviewing other people's work.
The Architecture Runway Concept
An idea that has stuck since SAFe popularised it: the architecture runway is the technical infrastructure already in place that supports near-term business needs without requiring extensive rearchitecture for each new capability. Building the runway is the architect's job, but it is not done as a separate project — it is delivered alongside business capabilities, with deliberate investment in the foundational pieces that the next several quarters of delivery will need. When the runway is healthy, delivery teams can ship features without unblocking architecture work first. When it is not, delivery slows because every initiative has to extend foundations.
A pattern that organisations underestimate: architecture work that is genuinely valuable but invisible to product roadmaps. Refactoring identity infrastructure, simplifying integration patterns, retiring duplicate platforms, normalising data models. None of these features ship to customers. All of them determine whether the next two years of customer-facing delivery is fast or slow. The mature delivery model funds runway work explicitly rather than expecting it to happen between feature deliveries.
Lightweight Architecture Decision Records
Architecture Decision Records (ADRs) are the most useful agile EA practice that has emerged. An ADR is a short document — typically one to two pages — capturing a specific architecture decision: the context, the options considered, the decision made, and the consequences. ADRs are written incrementally as decisions are made, stored in source control next to the code they relate to, and kept short enough that engineers actually read them. The cumulative result is a navigable history of architectural decisions that beats either a comprehensive document nobody updates or a tribal memory that disappears with team turnover.
The Practical Operating Model
- Architects embedded in delivery teams or rotating across them, not in a separate review group
- Just-enough up-front architecture for each initiative — sized to the risk and reversibility of decisions
- ADRs written incrementally and stored with the code they relate to
- Architecture runway funded explicitly as part of the portfolio, not as a side activity
- Architecture review focused on patterns and standards, not on individual designs that comply with them
- Standards and reference architectures kept lightweight and maintained by the people who use them
The Frameworks Still Apply
Agile EA does not mean abandoning the established frameworks. TOGAF, the Zachman Framework, and others remain useful as conceptual maps and as shared vocabulary. What changes is how heavily their full ceremony is applied. Most organisations get more value from selective use of framework concepts (capability mapping, business architecture, data architecture, technology architecture) than from full ADM cycles for every initiative. The framework provides the language; the agile operating model provides the cadence.