TOGAF and Agile: Digital Transformation Architecture
A common myth is that Enterprise Architecture (EA) and Agile cannot coexist. People often see EA as a "ivory tower" where everything is designed up-front in a waterfall process, while Agile is about "failing fast" and building things incrementally.
In reality, successful digital transformation requires both. You need the agility to deliver quickly, and you need the architectural vision to ensure those deliveries aren't building a fragmented, unmanageable mess. This is the world of Agile Architecture.
Agile EA in One Paragraph
Agile Enterprise Architecture applies TOGAF's ADM in short, iterative cycles aligned to delivery sprints rather than long waterfall phases. Architects work "just in time" — designing just enough architecture to support the next 1–3 sprints, while maintaining strategic direction through a multi-layer cycle model. This eliminates Big Design Up Front without abandoning architectural coherence.
Moving Away from "Big Design Up Front" (BDUF)
In the old days of EA, architects would spend 6 months designing a 300-page "Architecture Definition Document" before a single line of code was written. This is called Big Design Up Front (BDUF).
In a digital transformation, this approach fails because by the time the design is finished, the business requirements have already changed.
The Agile Architecture Alternative: "Just-In-Time" Design
Agile EA focuses on Just-In-Time (JIT) design. This means designing just enough of the architecture to support the current and next few sprints. You don’t design for every possible future; you design for the immediate needs while keeping your eyes on the long-term strategic goals.
Mapping the TOGAF ADM to Agile
How do we actually use the ADM in an Agile environment? The key is to run the ADM in shorter, faster cycles (Iterations).
- Strategic Cycle (Long-term): Running a high-level ADM cycle (Preliminary through Phase H) over a 6-12 month horizon to set the overall direction.
- Segment/Program Cycle (Mid-term): Running an ADM cycle for a specific value stream or program every 2-3 months.
- Capability/Sprint Cycle (Short-term): Running a very lightweight ADM cycle for a specific team every 2-4 weeks.
This layered approach ensures that the "Big Picture" (TOGAF) and the "Delivery Speed" (Agile) stay in sync.
The "Architecture Runway" Concept
A key concept in Agile Architecture is the Architecture Runway. Think of a runway for a plane: the plane (the delivery team) needs a safe, smooth surface to take off.
The "runway" consists of the technical infrastructure, APIs, data models, and standards that the teams need to deliver features without hitting a wall. The architect's job is to stay 1-2 steps ahead of the delivery teams, building out the runway just before it's needed.
If the runway is too short, the delivery team has to stop and build it themselves, which slows down the "velocity." If the runway is too long, you've wasted time building things that might never be used.
Why Agile EA is Growing in Popularity
1. Faster Time to Market
By breaking the architecture into smaller, deliverable pieces, you can start seeing value from your digital transformation much sooner.
2. Better Stakeholder Alignment
In Agile EA, the architect is part of the delivery team. They are in the daily stand-ups and the retrospectives. This means they can adjust the architecture instantly based on real-world feedback.
3. Reduced Risk
Waterfall EA is a "big bet" — if the design is wrong, you don't find out until after months of work. Agile EA allows you to "fail fast" and pivot the architecture before millions have been spent.
Common Pitfalls When Applying Agile EA
Even experienced architects make these mistakes when adopting Agile Architecture:
- Skipping governance because "we’re agile." Agile EA means lightweight governance, not no governance. Architecture Contracts and Compliance Reviews still apply — they are just faster and leaner.
- Building too much runway. If the architecture runway is 6 months ahead of delivery, you have returned to BDUF. Keep it 1–2 sprints ahead.
- Treating architecture as a separate stream. In true Agile EA, the architect is embedded in the delivery team — attending sprint planning, retrospectives, and demos. Remote architecture that only surfaces in review meetings is not Agile EA.
- Not updating the Architecture Repository. Agile speed can mean documentation falls behind. Build documentation updates into the Definition of Done for architecture tasks.
For a deeper understanding of how the ADM is structured for iteration, see TOGAF ADM iteration and scoping. The official guidance on TOGAF and Agile is covered in the TOGAF Series Guide on Agile Architecture from The Open Group.
Practical Application: Running Agile EA in a Scrum Environment
Here is a concrete example of how an enterprise architect operates within a Scrum-based delivery team using the Agile EA model:
Sprint 0 (Architecture Runway Setup) Before the delivery team’s first sprint, the architect completes a lightweight Phase A and B cycle. They identify the key business capabilities being delivered, define the integration requirements, and document 3–5 architecture decisions as Architecture Decision Records (ADRs). These ADRs become the "rails" the delivery team runs on.
Sprint 1–3 (Active Delivery) The architect attends sprint planning to review new user stories for architecture implications. Any story that introduces a new integration, data entity, or technology component triggers a brief architecture review — typically a 30-minute discussion, not a formal board review. The architect updates the Architecture Repository in the Definition of Done for architecture tasks.
Every 3rd Sprint (Architecture Review Cycle) The architect initiates a lightweight ADM iteration review. They assess whether the evolving application aligns with the target architecture, check for new compliance requirements, and extend the architecture runway for the next three sprints. This is a 2-hour working session, not a formal project.
Phase G Touchpoints At major delivery milestones (typically every 3–4 months), a formal Architecture Compliance Review is conducted by the Architecture Board. This is the one formal governance gate — but because the architect has been embedded throughout, there are rarely surprises.
This model keeps architecture visible, responsive, and trusted by delivery teams. The key principle: the architect’s cadence matches the delivery cadence, not a separate governance calendar.
Summary
Modern Enterprise Architecture is not about control; it’s about enablement. By embracing Agile principles, you can turn your architecture from a bottleneck into an accelerator. You can guide your organization’s digital transformation with a clear vision while still delivering at the speed of the market.
In our next post, we’ll look at how to build a team that can handle this complexity: The Architecture Capability Framework — Building Maturity.
This post is part of the TOGAF 9.2 Masterclass series. Don’t forget to check out our previous post on The Architect’s Journey — Career Paths & Roles.
Common Challenges Applying TOGAF in Agile Environments
TOGAF produces too much documentation for a sprint-based team The ADM was designed with large enterprise transformation programmes in mind — its full deliverable set can run to dozens of documents. In Agile contexts, trim deliverables to the minimum that communicates architectural intent. An Architecture Decision Record (ADR) can replace a formal Architecture Definition Document for small initiatives. The Open Group's TOGAF Agile guidance endorses this tailoring approach explicitly.
Architects are pulled into sprint ceremonies without a clear role In scaled Agile (SAFe, LeSS), the enterprise architect needs a clearly defined interface with delivery teams. The most effective model is a "just enough architecture" runway: the architect defines constraints and patterns several sprints ahead, delivery teams implement within those guardrails without waiting for approval on every decision. The architecture team attends PI Planning (SAFe) or Sprint Reviews when architecture-impacting decisions are being made.
Architecture governance becomes a bottleneck A formal Architecture Board review process with two-week turnaround times is incompatible with two-week sprints. Solutions include: pre-approved architectural patterns that teams can adopt without review, an "exception-only" governance model where teams only escalate when they deviate from standards, and embedded architects on delivery teams who can make real-time decisions within guardrails.
Digital transformation initiatives bypass the architecture function entirely Fast-moving digital programmes often procure cloud services, SaaS tools, and third-party integrations without architecture involvement — creating shadow IT and technical debt. The architecture team must be a business-facing enabler, not a gatekeeper. Positioning the Architecture Repository as a living reference (not a compliance artefact) and joining product discovery conversations early keeps the architecture function relevant without slowing delivery.
Frequently Asked Questions
How does TOGAF relate to SAFe (Scaled Agile Framework)? SAFe and TOGAF are complementary. SAFe defines how Agile delivery is organised at scale (teams, trains, ARTs, Portfolio). TOGAF defines how enterprise architecture governs the technology direction across those delivery units. The Enterprise Architect in a SAFe organisation typically owns the Solution and Enterprise Architecture work streams, using the ADM to define the target state while SAFe ceremonies drive iterative delivery toward it. The SAFe Enterprise Architect role description describes this interface.
What is TOGAF's guidance on digital transformation architecture? TOGAF 10 added explicit guidance on digital transformation, recognising that traditional ADM cycles designed for multi-year programmes do not fit the pace of digital initiatives. The key adjustment is iterating the ADM in shorter cycles (Phase A through E in weeks, not months) and prioritising business outcome architecture over infrastructure architecture. The Preliminary Phase is used to establish digital architecture principles that guide autonomous team decisions. See the TOGAF 10 digital transformation guidance on The Open Group website.
Can TOGAF be used alongside OKRs (Objectives and Key Results)? Yes. OKRs and TOGAF operate at different levels. OKRs define business outcomes over quarterly cycles; TOGAF defines the architecture that enables those outcomes over longer horizons. The Architecture Vision (Phase A) can be aligned to OKRs by tracing business drivers through to architecture principles and target state designs. When OKRs change direction significantly, Phase A is revisited to assess architectural impact before delivery teams are redirected.