Overview

The Scaled Agile Framework (SAFe) excels at coordinating delivery across multiple teams and focuses on execution. In contrast, Enterprise Architecture (EA) delivers the framework which develops the capabilities which are necessary for planning and execution. Large-scale agile transformations often hit a “complexity ceiling” which cannot be understood and handled without EA concepts, methods and tools. SAFe organisations are fast at delivering code but slow at delivering value due to accumulating technical debt, fragmented standards, lack of strategic coherence and over-indulgence with their own processes. EA structures agile delivery and makes organisational complexity manageable.

The gap: why SAFe alone is not enough

SAFe operates on the principle of decentralised decision-making, empowering Agile Release Trains (ARTs) to move quickly. However, in complex enterprises, fully decentralised architecture (as an after-the-fact reality of agile delivery) often leads to “accidental architecture”, a landscape where short-term speed compromises long-term stability. A necessary realisation for both to co-exist productively is that agile is reactive while EA is proactive.

The “runway” problem

SAFe introduces the concept of the Architectural Runway: existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign. Agile teams are incentivised to deliver features (business value) for the *current Program Increment (PI) and not to curate the runway for future PIs that are 6-12 months out. EA provides the intentional architecture *required to build this runway ahead of demand. EA looks beyond the current PI to the multi-year strategic horizon, ensuring that when the ARTs arrive at a complex feature (e.g., “Implement AI-driven fraud detection”), the necessary data lakes, compliance standards, and API gateways are already in place.

Silos and interoperability

Agile teams often optimise for their specific product value stream with a focus on reaction time and low time-to-production; dependencies to other teams and long communication paths within the organisation impact those metrics negatively, which drives teams to silo-in, replicating capabilities inside their silo which should be sought elsewhere in the organisation. Some organisational models tackle this with dedicated structures eg. Team Topologies. For instance, a team working on “Mobile Banking” might choose a technology stack that is incompatible with the “Loan Processing” team, leading to integration nightmares, technology fragmentation and increased operational costs. EA anticipates functional and non-functional needs, ensures interoperability standards and cross-domain alignment. It ensures that autonomy does not devolve to anarchy by defining the guardrails (how we do things) and governance (how we agree on how we do things) within which agile teams can innovate freely.

Governance and Compliance

In regulated industries (finance, healthcare, defence), “move fast and break things” is not a viable strategy. Pure agile backlog management often treats non-functional requirements (NFRs) like security and compliance as “just another story” that can be de-prioritised; this works well, self-enforcing a feature-first culture, until applications hit the realities of production workloads. EA elevates NFRs to *architectural constraints *that cannot be negotiated away. It ensures that the system is secure by design and compliant by default, rather than trying to bolt on compliance at the end of a sprint.

Integrating TOGAF with SAFe: the agile architecture extension

The TOGAF Standard, 10th Edition acknowledges that the traditional waterfall approach to architecture (Big Design Up Front) is obsolete. Instead, it introduces Agile Architecture concepts that bridge the gap between high-level strategy and sprint-level execution.

The TOGAF Series Guide: Enabling Enterprise Agility

This guide explicitly redefines the role of the architect from “gatekeeper” to “enabler.” It maps TOGAF’s Architecture Development Method (ADM) to agile cycles, ensuring architecture evolves iteratively.

**Preliminary & Phase A (Vision) → strategic themes **and p****ortfolio vision: instead of a static 5-year plan, TOGAF uses Phase A to define strategic themes that feed directly into the SAFe Portfolio. This ensures that every epic funded in the Portfolio Kanban aligns with the enterprise’s long-term business goals.

**Phase B, C, D (Business, Info Systems, Tech) → solution intent *and e****nablers: these phases are no longer about writing extensive solution designs. In an agile context, they are about defining the solution intent: *the repository of current and intended behaviour.

• TOGAF Contribution: Defines the “rigid” parts (eg. statutory compliance, core transaction systems, operations standards).
• SAFe Contribution: Defines the “flexible” parts (eg. UI/UX, specific feature logic).
• Result: A Minimum Viable Architecture that is just enough to start, but robust enough to scale.

Phase E & F (Opportunities & Migration) → epics and a****rchitectural runway: the output of TOGAF Phase E is not a rigid project plan, but a set of enabler epics. These are large architectural initiatives (e.g., “migrate to cloud,” “implement single sign-on”) that are injected into the SAFe program backlog to ensure the runway is extended.

Intentional Architecture vs. Emergent Design

The TOGAF Agile Specialist guidance emphasises a balance:

• Intentional Architecture (Top-Down): Driven by EAs using TOGAF. Focuses on cross-program concerns, major technology choices, and non-functional requirements.
• Emergent Design (Bottom-Up): Driven by SAFe System Architects and teams. Focuses on the best way to implement specific user stories within the guardrails set by the Intentional Architecture.
• The Handshake: This collaboration happens during PI planning. EAs present the “Vision” and “Guardrails,” while teams present their implementation plans. Gaps are identified and resolved immediately, rather than months later.

Summary: the value of the hybrid approach

SAFe Alone	SAFe + Enterprise Architecture (TOGAF)
Risk: High technical debt due to short-term focus.	Benefit: Sustainable velocity via managed Architectural Runway.
Risk: Fragmented data and “Zombie” applications.	Benefit: Coherent Solution Intent and data interoperability.
Risk: Compliance is an afterthought (or a bottleneck).	Benefit: Compliance is built-in via architectural guardrails.
Risk: Teams optimise for themselves, not the enterprise.	Benefit: Systems Thinking ensures local decisions support global strategy.

Published 07 Dec 2025

Post navigation