Agile EA

Agile EA is the response to a real tension: traditional EA's big-design-up-front conflicts with agile delivery's emphasis on iteration and learning. The naive resolution — abandon EA — produces agility without coherence. The mature resolution — agile EA — keeps architecture's value while working in a cadenced, emergent, just-enough way that complements agile delivery.

Agile EA is not 'less EA'; it is EA done differently. It produces lightweight, living artifacts rather than heavyweight one-time documents. It works in cadences aligned to delivery rather than in multi-year waterfall cycles. It treats the target state as emergent — informed by strategy but refined by learning — rather than as a fixed blueprint. And it enables delivery through paved roads rather than gating it through reviews.

This page covers the principles of agile EA, just-enough architecture, cadenced practice, emergent target states, and how agile EA blends with frameworks like TOGAF and with product operating models.

The tension is genuine. Traditional EA produces a comprehensive target state before delivery begins, assuming the destination is knowable in advance. Agile delivery assumes the destination is discovered through building, and that locking it early produces the wrong thing, well-architected. Both are partially right.

The naive resolution — choosing agile and dropping EA — feels fast but produces incoherence: teams iterate quickly toward locally optimal solutions that do not compose into a coherent enterprise. The naive opposite — forcing big-design-up-front on agile teams — produces documents teams ignore and a target state that is stale by the time it is delivered.

Agile EA resolves the tension by separating two things that traditional EA conflated: thinking (which should be early and ongoing) and commitment (which should be delayed as long as responsible). Agile EA thinks ahead — principles, reference architecture, the shape of the target state — but commits late, letting delivery learning refine the specifics. This is 'delay commitment, not delay thought.'

Just-enough architecture is the principle of providing the architecture needed to proceed safely, and no more. It is not 'no architecture'; it is architecture proportionate to the risk and reversibility of the decision. An irreversible decision (a core data model, a platform choice) deserves more architecture than a reversible one (a UI framework, a caching layer).

The heuristic is the 'last responsible moment' — delay a decision until you must make it, gathering information until then, but do not delay past the point where the decision becomes expensive or impossible to reverse. This requires judgment, which is why just-enough architecture is a senior practice, not a junior shortcut.

Just-enough architecture produces ADRs for the decisions made, reference architecture for the constraints that genuinely matter, and principles for the choices not yet made. It deliberately does not produce a comprehensive design up front, because that design would be based on assumptions that delivery will prove wrong.

Agile EA runs in cadences, not in multi-year cycles. The EA team works in sprints or iterations aligned to delivery: refining the reference architecture, updating standards, reviewing solutions, and feeding back learning — regularly, not annually. This keeps the architecture current with what delivery is actually building.

The cadence also applies to artifacts. Living artifacts are updated continuously: the capability map is refined as capabilities evolve, the standards catalogue is reviewed each quarter, the reference architecture is updated as patterns prove or fail. An artifact that is not updated is dead; agile EA treats artifacts as products with releases, not as one-time deliverables.

This cadenced practice is what lets EA stay relevant in an agile enterprise. A multi-year EA cycle in a quarterly-delivery enterprise is always out of date; a cadenced EA practice evolves with delivery, shaping it continuously rather than describing it retrospectively.

In agile EA, the target state is directional, not definitive. It states the direction (the principles, the shape, the capabilities being built toward) and a horizon, but it is refined as delivery produces learning. This is not 'no target state' — a directional target is essential to keep delivery coherent — but it is a target treated as a hypothesis, refined by evidence.

Emergent target states require a different kind of rigor: the rigor of stating assumptions, testing them through delivery, and updating the target when they fail. Traditional EA's rigor was in the completeness of the upfront design; agile EA's rigor is in the discipline of the feedback loop between delivery and target.

The risk of emergence is drift — the target state shifting imperceptibly toward whatever delivery happened to build, losing strategic intent. The safeguard is regular realignment with strategy (see EA and Business Strategy Alignment) and explicit updates to the target state when it changes, so emergence is visible and intentional rather than silent.

TOGAF and agile EA are often presented as opposites; in practice they blend well. TOGAF's ADM is explicitly iterative and tailorable — it can be run in cadenced cycles aligned to delivery sprints rather than as a waterfall programme. The phases become a checklist for each iteration rather than a sequence to complete once.

The practical blend: run Phase A (Vision) lightly per initiative; compress B/C/D into a single architecture-definition iteration for smaller scopes, expanding for larger; treat E/F (migration planning) as the rolling roadmap; and run G (governance) continuously as lightweight reviews. The ADM as a scaffold, tailored to cadenced delivery, is a powerful agile EA method.

The key is to resist the gravitational pull of comprehensive documentation. TOGAF supports tailoring; the failure is not tailoring and producing documents that agile teams will not read. The agile EA practitioner uses TOGAF's phases as a completeness checklist while producing only the artifacts that will actually be used.

Agile EA aligns naturally with product operating models, where teams own products end-to-end and evolve them continuously. In this model, EA's role shifts further toward enablement: providing the paved road (platform, reference architecture, standards) that product teams use, rather than reviewing each product team's designs.

This is the convergence of agile EA with platform engineering. The platform becomes the primary mechanism of EA: it embodies the reference architecture and standards, and product teams consume it. EA governance shifts from reviewing every design to ensuring the platform is right and handling exceptions.

The operating model also requires EA to think in products — the capability map, the reference architecture, the standards catalogue are each products with users (the delivery teams) and owners (EA). Treating EA artifacts as products with user feedback and release cadences is the agile EA expression of the product operating model.