TOGAF ADM Phases: Complete Guide for 2026

The Architecture Development Method (ADM) is the heart of TOGAF. It is a cyclical, iterative process that describes how to develop and maintain an enterprise architecture. Unlike a linear project methodology, the ADM is designed to be revisited — each architecture cycle builds on the last, and each phase feeds continuously into Requirements Management.

This guide covers all 10 ADM phases in the order they appear in the TOGAF 10 standard, explaining what triggers each phase, what activities happen within it, and what outputs it produces.

The ADM at a Glance

Preliminary Phase
      ↓
Phase A — Architecture Vision
      ↓
Phase B — Business Architecture
      ↓
Phase C — Information Systems Architecture (Data + Application)
      ↓
Phase D — Technology Architecture
      ↓
Phase E — Opportunities and Solutions
      ↓
Phase F — Migration Planning
      ↓
Phase G — Implementation Governance
      ↓
Phase H — Architecture Change Management
      ↑___________________↑ (continuous cycle)

Requirements Management runs throughout ALL phases

Preliminary Phase — Setting Up for Architecture Work

What it is

The Preliminary Phase is not a project phase in the conventional sense — it is the preparation work done before any specific architecture engagement begins. It establishes the organisation's architectural capability, defines who has authority to approve architecture work, and customises TOGAF (and any other frameworks in use) to the organisation's context.

Key activities

• Defining the organisational scope: which business units and systems does the enterprise architecture practice cover?
• Establishing the Architecture Governance structure — who approves what?
• Identifying and confirming Architecture Principles (the rules the architecture must comply with)
• Selecting and tailoring the TOGAF ADM and any other methods or frameworks in use
• Implementing the Architecture Repository (the store for all architecture artefacts)

Key outputs

• Tailored Architecture Framework (the customised version of TOGAF for the organisation)
• Architecture Principles document
• Established Architecture Repository
• Architecture Governance framework documented

Exam tip

The Preliminary Phase establishes capability and governance, not project deliverables. Questions about principles, governance structures, and the Architecture Repository often reference the Preliminary Phase.

Phase A — Architecture Vision

What it is

Phase A kicks off a specific architecture engagement. It defines the scope of the work, obtains stakeholder buy-in, and produces a high-level view of what the end-state architecture will look like — the Architecture Vision.

Triggered by

A Request for Architecture Work — a formal request from a business sponsor for the architecture team to undertake a specific engagement.

Key activities

• Defining the scope and constraints of the architecture project
• Identifying and analysing stakeholders
• Confirming and refining Architecture Principles for this engagement
• Developing the Architecture Vision (the high-level future-state view)
• Identifying the business value of the architecture work
• Creating the Statement of Architecture Work — the formal document that commissions the engagement

Key outputs

Exam tip

The Statement of Architecture Work is the key deliverable of Phase A. It is approved by the sponsoring organisation and authorises the work. The Architecture Vision is also produced here — not in Phase B.

Phase B — Business Architecture

What it is

Phase B develops the baseline (current state) and target (future state) Business Architecture — the description of the business strategy, governance, organisation, and key business processes.

Key activities

• Selecting relevant Architecture Viewpoints for business stakeholders
• Identifying relevant Architecture Building Blocks (ABBs) from the Architecture Repository
• Conducting gap analysis between baseline and target Business Architecture
• Selecting candidate Architecture Roadmap components for Phase E

Key outputs

• Baseline Business Architecture description
• Target Business Architecture description
• Business Architecture gap analysis
• Updated Architecture Repository
• Updated Architecture Roadmap components (business perspective)

Architectural artefacts (Phase B examples)

• Organisation Chart
• Business Footprint Diagram
• Business Service/Function Catalogue
• Actor/Role Matrix
• Business Interaction Matrix
• Process Flow Diagrams

Exam tip

Phase B produces the Business Architecture, not technology decisions. Any question about mapping business processes to IT capabilities, or identifying business-IT gaps, is likely answered by Phase B activities.

Phase C — Information Systems Architecture

What it is

Phase C develops the Data Architecture and Application Architecture in parallel (or sequentially, depending on the organisation). Together these describe what data the enterprise manages and what applications handle it.

Two sub-phases

Phase C — Data Architecture: Describes the structure of the organisation's logical and physical data assets, and how they flow between systems. Produces entity models, data dictionaries, data lifecycle diagrams, and the conceptual data model.

Phase C — Application Architecture: Describes the logical software systems needed to handle data and support business functions. Produces application portfolios, application interaction diagrams, and application/user location diagrams.

Key activities

• Selecting relevant viewpoints for technical stakeholders
• Developing the Data and Application Architecture descriptions (baseline and target)
• Performing gap analysis for both data and application
• Identifying candidate roadmap components

Key outputs

• Baseline and Target Data Architecture
• Baseline and Target Application Architecture
• Data and Application gap analyses
• Updated Architecture Roadmap components

Exam tip

The four architecture domains in TOGAF are Business (Phase B), Data, Application (both Phase C), and Technology (Phase D). Remember them as BDAT — they appear in exam questions about which phase covers which domain.

Phase D — Technology Architecture

What it is

Phase D describes the logical software and hardware infrastructure that supports the deployment of business, data, and application services. It maps the technology building blocks needed to implement the target architecture.

Key activities

• Developing the Technology Architecture: servers, networks, middleware, platforms, cloud infrastructure, security infrastructure
• Performing gap analysis between baseline and target technology landscape
• Selecting appropriate Technology Architecture Building Blocks
• Confirming technology standards

Key outputs

• Baseline and Target Technology Architecture
• Technology gap analysis
• Updated Architecture Roadmap (technology components)
• Technology Standards Catalogue

Architectural artefacts (Phase D examples)

• Environments and Locations Diagram
• Platform Decomposition Diagram
• Processing/Network Diagrams
• Technology Standards Catalogue
• Technology Portfolio Catalogue

Exam tip

Phase D is not about selecting specific vendors or products — it describes logical technology building blocks. Vendor selection typically happens later, during implementation. This is a common trap in exam questions.

Phase E — Opportunities and Solutions

What it is

Phase E is the first ADM phase with an explicit delivery focus. It identifies the major work packages needed to move from baseline to target architecture and defines the overall Implementation and Migration Strategy.

Key activities

• Reviewing the gap analysis outputs from Phases B, C, and D
• Grouping gaps into work packages and projects
• Assessing the organisation's capability to implement the required changes
• Identifying dependencies between work packages
• Defining the implementation strategy (big-bang vs. phased; greenfield vs. evolutionary)
• Producing the initial Architecture Roadmap

Key outputs

• Implementation and Migration Strategy
• Architecture Roadmap (initial version, with work packages sequenced)
• Transition Architectures (intermediate states between baseline and target)
• Capability Assessment

Exam tip

The Architecture Roadmap is first produced in Phase E (though it evolves through Phase F). Transition Architectures — the intermediate states the organisation passes through on the way to the target — are also a Phase E concept. Many candidates confuse Phase E (strategy and roadmap) with Phase F (migration plan).

Phase F — Migration Planning

What it is

Phase F turns the Implementation and Migration Strategy from Phase E into a formally prioritised, resourced, and scheduled Migration Plan. It coordinates with portfolio management, programme management, and project management to ensure architectural intent is reflected in actual delivery plans.

Key activities

• Finalising the Architecture Roadmap
• Coordinating with business planning and IT planning cycles
• Prioritising work packages based on business value, risk, and dependencies
• Confirming that Transition Architectures are achievable and properly sequenced
• Producing the Implementation and Migration Plan

Key outputs

• Finalised Architecture Roadmap
• Implementation and Migration Plan (prioritised work packages with schedules, costs, and resources)
• Updated Transition Architectures
• Updated Architecture Repository

Exam tip

The distinction between Phase E and Phase F: Phase E identifies what needs to be done and in what order (roadmap); Phase F confirms how it will actually be done (migration plan with resources and schedules). If a question mentions prioritisation, cost, and scheduling of work packages, the answer is Phase F.

Phase G — Implementation Governance

What it is

Phase G ensures that the implementation projects being executed actually deliver the architecture as specified. It is the governance phase — the architecture team doesn't build anything in Phase G; they oversee the build.

Key activities

• Confirming scope and priorities with the sponsoring organisation
• Identifying deployment resources and skills
• Issuing Architecture Contracts — formal agreements between the architecture team and development/solution teams
• Performing architecture compliance reviews as projects progress
• Handling exceptions where implementations deviate from the target architecture

Key outputs

• Architecture Contract (between architecture team and implementation teams)
• Compliance Assessment reports
• Change Requests (if deviations require formal architecture changes)
• Updated Architecture Repository

Exam tip

Architecture Contracts are a Phase G concept. They define the obligation of development teams to deliver in accordance with the target architecture. This is distinct from the Statement of Architecture Work (Phase A) which commissions the architecture engagement itself.

Phase H — Architecture Change Management

What it is

Phase H is the ongoing monitoring and change management phase. Once an architecture has been implemented, Phase H watches for drivers of change (technology developments, business strategy shifts, regulatory changes) and manages architecture updates in a controlled way.

Key activities

• Establishing an Architecture Change Management process
• Monitoring technology and business trends for architecture implications
• Assessing change requests for architecture impact
• Deciding whether a change requires a new ADM cycle (full or partial)
• Maintaining the Architecture Repository to reflect the current architecture

Key outputs

• Architecture updates
• Changes to Architecture Framework and principles (if required)
• New Request for Architecture Work (triggering a new ADM cycle) when change is significant enough

Exam tip

Phase H is often confused with Phase G. Phase G governs active implementation; Phase H governs the deployed architecture over time. Phase H is triggered by change requests and technology/business events — it feeds new Requests for Architecture Work back to Phase A, completing the ADM cycle.

Requirements Management — The Continuous Phase

What it is

Requirements Management is not a sequential phase — it is a continuous process that runs throughout all other ADM phases. Its purpose is to manage all architecture requirements as they are identified, stored, and fed into and out of each phase.

Key activities

• Identifying, storing, and maintaining architecture requirements throughout the ADM cycle
• Assessing the impact of new requirements on current architecture work
• Prioritising requirements and managing conflicts between stakeholder needs
• Ensuring requirements are dispositioned (addressed, deferred, or rejected) and tracked

Why it matters

Requirements rarely stay static. Stakeholders identify new needs, business conditions change, and technical constraints emerge throughout an architecture project. Requirements Management ensures these changes are captured systematically and that their impact on in-progress architecture work is assessed — rather than being handled informally or missed entirely.

How the ADM Phases Connect

Each phase produces outputs that become inputs to the next:

ADM and the Architecture Repository

The Architecture Repository is not a phase — it is the store for all architecture artefacts produced across all phases. It contains:

• Architecture Metamodel — the organisation's tailored architecture framework
• Architecture Capability — skills and processes of the EA team
• Architecture Landscape — current architectural descriptions (Strategic, Segment, Capability)
• Standards Information Base — approved technologies, products, and standards
• Reference Library — guidelines, templates, and patterns
• Governance Log — governance decisions, compliance assessments, waivers

What to Study Next

Now that you understand the ADM phases, the next areas to master for the TOGAF certification exam are the Architecture Content Framework (the metamodel for architecture artefacts), the Enterprise Continuum (how the Architecture Repository is organised from generic to specific), and the Architecture Governance structure.

See our full TOGAF Certification Complete Guide for a structured exam preparation path, and our TOGAF 9.2 Masterclass which covers all ADM phases with interactive module-by-module exam prep.