TOGAF ADM Cycle Explained: All 10 Phases Made Simple

Introduction to TOGAF and the ADM Cycle

Hello and welcome to the TOGAF 9 Architecture Development Cycle Quick Reference Guide. In this session, you'll get a clear, easy-to-understand overview of the important activities performed in each phase of the ADM.

Let's start by understanding exactly what TOGAF is.

What is the TOGAF ADM? (Quick Answer)

The TOGAF Architecture Development Method (ADM) is a step-by-step process for developing enterprise architecture. It consists of a Preliminary Phase plus nine lettered phases (A through H), with Requirements Management at the centre. Each phase has defined inputs, activities, and outputs that ensure IT investments align with business strategy.

What is TOGAF?

The term TOGAF stands for The Open Group Architecture Framework. It is the de-facto global standard for Enterprise Architecture, and any enterprise organization can use it freely.

TOGAF provides a comprehensive set of tools, vocabulary, and a step-by-step method to build an Enterprise Architecture (EA).

It was initially developed in 1995, based heavily on the Technical Architecture Framework for Information Management (TAFIM), which was created by the US Department of Defense (DoD). Today, The Open Group consortium continually develops and maintains TOGAF.

The TOGAF ADM Cycle Overview

The Architecture Development Method (ADM) is the beating heart of TOGAF. It describes a proven method for developing and managing the lifecycle of enterprise architecture.

The ADM cycle is a combination of ten separate, distinct phases. Each ADM phase integrates various architectural assets to ensure the IT landscape perfectly aligns with the business goals of the organization.

Let's break down the objective and the crucial activities performed in each phase.

Preliminary Phase

The very first step of the TOGAF ADM cycle is the Preliminary Phase. You can think of this as the "preparation" phase. The objective here is to determine and establish the architecture capability desired by the organization before any actual architecture design begins.

Key activities performed:

Prepare the organization for successful TOGAF architecture projects.
Define what "Architecture" means to this specific enterprise.
Customize the TOGAF framework to fit the organization's specific needs.
Select the tools that will be used.
Define the core Architecture Principles.

Phase A: Architecture Vision

Once the organization is prepared, we move to Phase A: Architecture Vision. The primary objective is to define the scope, identify the stakeholders, create the architecture vision, and obtain approvals to proceed.

Key activities performed:

Set the scope, constraints, and expectations for the project.
Identify key stakeholders and their primary concerns.
Create an Architecture Vision Document.
Validate the business context and create the Statement of Architecture Work.
Obtain formal approvals to move to the next phase.

Phase B: Business Architecture

Phase B focuses on the development of the Business Architecture. This demonstrates how the business will realistically operate to achieve the vision defined in Phase A.

In practical terms, this phase is crucial for demonstrating the business value of the subsequent architecture work to key stakeholders.

Key activities performed:

Select reference models, viewpoints, and tools.
Define the Baseline (Current State) Business Architecture.
Define the Target (Future State) Business Architecture.
Perform a gap analysis between the baseline and target.
Create the Architecture Definition Document.

Phase C: Information Systems Architectures

Phase C is actually a combination of two distinct architectures: Data Architecture and Application Architecture. It describes how the Information Systems will allow the Business Architecture to function.

It describes the fundamental organization of an IT system by defining:

The major types of information and the applications that process them.
The relationships between these applications and the environment.
The principles governing their design and future evolution.

Phase D: Technology Architecture

With the Business, Data, and Application architectures defined, Phase D focuses on the Technology Architecture. This is the physical and logical infrastructure required to run the applications.

Technology Architecture describes:

Hardware, software, and communications networks (servers, cloud infrastructure, routers).
The relationships between these physical/virtual components.
The guiding principles for technology selection.

By the end of Phase D, the logical blueprint of the Target Enterprise Architecture is complete.

Phase E: Opportunities and Solutions

In Phase E, the focus shifts from design to delivery. The goal is to identify the delivery vehicles (projects, programs, or portfolios) that will actually build the Target Architecture.

Key activities performed:

Consolidate and prioritize the gaps found in Phases B, C, and D.
Group the gaps according to their dependencies to form major implementation projects.
Determine if a single "Big Bang" implementation is possible, or if an incremental approach (using Transition Architectures) is required.
Assess priorities and schedule projects based on business value and urgency.

Phase F: Migration Planning

Working closely with portfolio and project managers, Phase F addresses exactly how to move from the Baseline to the Target Architecture by finalizing a detailed Implementation and Migration Plan.

Key activities performed:

Cost/Benefit Analysis: Assess the business value of every proposed project.
Risk Assessment: Identify which projects carry high risk and plan mitigation strategies.
Prioritize projects based on value and risk, locking them into the migration plan.
Conclude transition planning.

Phase G: Implementation Governance

In Phase G, the implementation projects are formally kicked off. The role of the enterprise architect shifts from designer to overseer. The architecture team provides governance to ensure the build teams don't deviate from the blueprint.

Key activities performed:

Provide architectural oversight for the implementation teams.
Prepare and issue Architecture Contracts.
Ensure that the final implemented systems actually conform to the Target Architecture designed in Phases B, C, and D.

Phase H: Architecture Change Management

Even after a system is deployed, the world continues to change. Phase H establishes procedures for managing changes to the new architecture over time.

Key activities performed:

Continuously monitor requests for governance, new technology developments, and changes in the business environment.
Determine if a change is small (requiring a simple patch) or large (requiring a completely new cycle of the ADM to be initiated).
Ensure the architecture continues to maximize business value.

Requirements Management (The Center of the ADM)

If you look at diagrams of the ADM, you will notice Requirements Management sitting directly in the center of the cycle.

This indicates that the ADM is continuously driven by requirements. It is a dynamic process—requirements are identified, stored, fed into, and fed out of every single phase of the ADM constantly. Every stage of a TOGAF project must validate and address business requirements.

Key Outputs Per Phase (Quick Reference)

Understanding what each phase produces is essential for both the exam and real-world practice:

Phase	Primary Output
Preliminary	Architecture Principles, Governance Framework
Phase A	Architecture Vision, Statement of Architecture Work
Phase B	Business Architecture Document
Phase C	Information Systems Architecture (Data + Application)
Phase D	Technology Architecture Document
Phase E	Architecture Roadmap (initial), Work Package definitions
Phase F	Implementation and Migration Plan
Phase G	Architecture Contracts, Compliance Assessments
Phase H	Architecture Updates, Change Requests
Req. Mgmt	Requirements Repository (active throughout)

How to Apply the ADM in Practice

The ADM is not a rigid waterfall sequence that must be followed exactly as written. TOGAF explicitly supports iteration — running the ADM at different levels of scale and detail simultaneously. For a deeper dive into this, see our guide on TOGAF ADM iteration and scoping.

In Agile environments, architects often compress phases into shorter cycles. The ADM maps naturally onto agile delivery rhythms — the TOGAF and digital transformation guide explains exactly how.

For the official ADM specification, refer to the TOGAF standard published by The Open Group.

Exam Tips for the ADM Cycle

If you are preparing for the TOGAF Foundation (Part 1) exam, these ADM facts are almost always tested:

Requirements Management is NOT a sequential phase — it is a continuous, central process.
Phase E is where initial implementation planning begins, not Phase G.
Architecture Contracts are produced in Phase G, not Phase F.
The ADM is designed to be iterated and customized — there is no requirement to execute every phase for every project.

Test yourself with our TOGAF 9 practice questions and TOGAF certification exam questions.

Summary

The Architecture Development Method (ADM) forms the absolute core of TOGAF. It provides a proven, repeatable 10-step method for deriving an organization-specific Enterprise Architecture.

By following the ADM, organizations ensure that their massive IT investments directly support and enable their strategic business goals.