TOGAF ADM Iteration and Scoping: Applying the Method at Scale

One of the most common misunderstandings about the TOGAF ADM is that it is a single, linear process that an organization runs once and then is done. In reality, the ADM is designed to be iterated — run multiple times, at different levels of detail, across different parts of the enterprise, in overlapping and nested cycles.

This is what makes TOGAF scalable. A global corporation with thousands of systems and hundreds of business units cannot be architected in a single ADM cycle. A small government agency standing up a new digital capability does not need the full enterprise-scale ADM either. Iteration and scoping are the mechanisms that make the same framework work for both.

This post explains how TOGAF approaches iteration, how it defines different levels of architecture, and how architects scope the ADM to fit their specific situation.

ADM Iteration: The Core Concept

TOGAF is explicit that the ADM can be used iteratively. Iteration means running through the ADM cycle more than once. Each pass through the cycle can be applied to a different scope, level of detail, or set of concerns.

TOGAF identifies three main types of ADM iteration:

Architecture development cycles: Running the full ADM from Preliminary Phase through Phase H for a new scope of architecture work
Transition planning cycles: Cycling through Phases E, F, and G repeatedly to plan and govern multiple sequential work packages within a single target architecture
Architecture governance cycles: Cycling through Phase H repeatedly as change requests arrive, with some triggering a new full ADM cycle and others being handled as incremental updates

The Three Levels of Architecture

TOGAF defines three levels at which architecture can be developed and managed. These levels are not independent: they are nested, with higher levels providing the context for more detailed work below them.

Strategic Architecture

Strategic Architecture operates at the highest level. It describes the long-term direction of the enterprise and the major transformational changes needed over a multi-year horizon.

Strategic Architectures are typically:

Developed by senior enterprise architects in collaboration with executive leadership
Expressed at a high level of abstraction, covering the most important capabilities and technology directions
Updated infrequently — perhaps annually or when business strategy changes significantly
Used to set direction for all Segment and Capability Architecture work

A Strategic Architecture does not specify individual systems or detailed data models. It defines the overall shape of where the enterprise is heading and the key principles and constraints that will govern all decisions below it.

Segment Architecture

Segment Architecture operates at the level of a major business unit, value stream, or domain within the enterprise. It develops the architecture for a significant portion of the organization in enough detail to plan and govern real projects.

Segment Architectures are:

Developed by a combination of enterprise architects and domain architects
Aligned to the constraints and direction set by the Strategic Architecture
More detailed than Strategic Architecture — they cover specific capabilities, business services, and major application decisions
Updated on an annual or programme cycle

A retail bank might have separate Segment Architectures for Retail Banking, Wholesale Banking, Risk Management, and Corporate Functions. Each segment operates within the enterprise Strategic Architecture but has enough independence to develop and govern its own roadmap.

Capability Architecture

Capability Architecture is the most detailed level. It addresses a specific capability, project cluster, or solution in enough detail to directly guide implementation.

Capability Architectures are:

Developed by architects working closely with delivery teams
Aligned to the constraints and direction of the relevant Segment Architecture
Highly detailed — they specify specific systems, integration patterns, data models, and infrastructure configurations
Updated frequently as projects progress through delivery

The Levels Are Not Siloed

The three architecture levels are not independent workstreams. Each level must be consistent with the level above it. A Capability Architecture that contradicts its Segment Architecture, which contradicts the Strategic Architecture, creates exactly the kind of fragmentation and inconsistency that TOGAF is designed to prevent.

Scoping an ADM Engagement

When a new architecture development effort begins, one of the most important early decisions is scoping: defining exactly what this ADM cycle will address and what it will leave for other cycles.

TOGAF defines four dimensions of scope that must be decided in Phase A:

1. Enterprise Scope (Breadth)

Which parts of the enterprise are within scope for this ADM cycle? This might be the entire enterprise, a single division, a specific geography, or a defined set of business processes. Getting breadth right is critical: too narrow and the architecture misses important interdependencies; too broad and the effort becomes unmanageable.

2. Domain Coverage (Depth by Domain)

Which of the four architectural domains will be developed in this cycle? Not every ADM cycle needs to cover all four. A cyber security transformation programme might focus on Data Architecture and Technology Architecture while treating Business and Application as pre-determined constraints. A business process transformation might focus entirely on Business Architecture.

3. Time Horizon

What time period does the Target Architecture address? A Strategic Architecture might have a five-year horizon. A Capability Architecture might be targeted at an 18-month delivery cycle. Getting the time horizon right ensures that the level of detail is appropriate for the decisions being made.

4. Architecture Detail Level

How deeply will the architecture be developed? A high-level Strategic Architecture uses different levels of abstraction than a detailed Capability Architecture. The level of detail should be sufficient to guide the decisions that need to be made — neither more nor less.

Common ADM Iteration Patterns

Organizations using TOGAF in practice tend to settle into recurring iteration patterns that match their operating rhythm.

Annual Strategic Architecture Review

Once a year, the enterprise architect team runs a Phase H-to-Phase A cycle to review whether the Strategic Architecture remains aligned to current business strategy and to update it based on what has been learned from the previous year's delivery cycles. This triggers any necessary updates to the Segment Architectures.

Programme Architecture Cycle

For each major transformation programme, a Segment Architecture ADM cycle covers Phases A through F, producing the programme's Architecture Roadmap. Phase G then runs continuously as the programme delivers. Phase H monitors for change drivers. This cycle typically runs over one to three years.

Project Architecture Cycle

For each major project within a programme, a Capability Architecture ADM cycle covers Phases A through D in significantly compressed form, producing the detailed design the project team will build to. Phase G then governs compliance throughout the project's delivery lifecycle.

Compression Is Not the Same as Skipping

When iterating the ADM at a smaller scale, it is appropriate to compress the phases — spending days rather than weeks in each one. What is not appropriate is skipping phases entirely. A compressed Phase A still must define scope, engage stakeholders, and produce a Statement of Architecture Work. It just does so quickly.

Iterating Within Phases

TOGAF also acknowledges that iteration happens within phases, not just between them. The most common within-phase iteration is between Phase B (Business Architecture) and the information from Phase A.

As architects develop the Business Architecture in Phase B, they often discover requirements or constraints that were not apparent in Phase A. This might require going back to Phase A's Architecture Vision and updating it before Phase B can be completed. The ADM expects and accommodates this.

The same dynamic occurs between Phase C and Phase B. As the Application Architecture is developed, gaps or inconsistencies in the Business Architecture may be revealed. Phase C does not simply wait until Phase B is perfect before starting. The two phases inform each other iteratively until a consistent picture emerges.

Using the ADM with Other Frameworks

Part of effective scoping is deciding how the ADM will co-exist with other management frameworks the organization already uses.

TOGAF 9.2 includes guidance on integrating the ADM with several commonly used frameworks:

COBIT: For IT governance. COBIT's governance objectives provide context for TOGAF's architecture governance structures, particularly in the Preliminary Phase and Phase G
ITIL: For IT service management. ITIL processes for change management, service transition, and service operation need to integrate with TOGAF's Phase G and Phase H activity
SAFe / Agile: For agile delivery. TOGAF's architecture phases need to be compressed and positioned within programme increment planning cycles. Architecture Runway concepts from SAFe align naturally with TOGAF's Transition Architecture work in Phases E and F
PRINCE2 / PMI: For project management. Work packages from Phase E and F align to project initiations in these frameworks, and Phase G's compliance reviews align to project stage-gate governance

When to Start a New ADM Cycle

One of the judgement calls architects make regularly in Phase H is deciding whether an incoming change is significant enough to warrant a new ADM cycle, or whether it can be handled as an incremental update within the current governance framework.

Factors that typically trigger a new ADM cycle include:

A change in business strategy that fundamentally alters what capabilities the enterprise needs
A major external event such as a merger, acquisition, or regulatory overhaul
Technology disruption that requires the technology domain to be significantly reconsidered
Evidence that the current Target Architecture is no longer achievable or desirable within its original parameters

Factors that support handling a change incrementally without a new cycle include:

The change affects a single component without broader architectural implications
The change is a like-for-like replacement (for example, upgrading a platform version)
The change was anticipated in the Migration Plan and can be addressed within the existing work package structure

Summary

The TOGAF ADM is not a one-time process. It is a framework designed for continuous iteration across multiple levels:

Strategic Architecture: The long-term enterprise direction (multi-year, highly abstract)
Segment Architecture: Major domain or programme architectures (annual, moderate detail)
Capability Architecture: Specific project or capability designs (quarterly/project cycle, highly detailed)

Scoping decisions in Phase A — breadth, domain coverage, time horizon, and detail level — determine whether a given ADM cycle is strategic, segment, or capability in nature.

Iteration happens between cycles, between phases, and within phases. Architects who understand this flexibility can apply TOGAF proportionately and effectively regardless of the scale of the work they are doing.

This post completes Module 2 of the TOGAF 9.2 Masterclass. We have now covered the entire ADM from the Preliminary Phase through Phase H, including Requirements Management, the Architecture Requirements Specification, and iteration principles.

In Module 3, we move to TOGAF Architecture Tooling and Modeling — the practical tools and techniques architects use to document and communicate their designs. For the full series, start with What is TOGAF 9.2?.