The 8 Phases of TOGAF Explained (A–H)

In the world of enterprise architecture (EA), TOGAF (The Open Group Architecture Framework) is one of the most widely adopted methodologies. At its heart lies the Architecture Development Method (ADM): a structured, iterative cycle that guides architects to conceive, build, govern, and evolve an architecture that aligns business and IT.

Although TOGAF’s full ADM contains more than just eight steps (there is a preliminary step, as well as a continuous Requirements Management activity), the core of the method is often described in eight phases (A through H). 

In this article, we walk through each of those eight phases: what they aim to do, how they interlock, and what deliverables or pitfalls to watch out for, with examples and metaphors to bring them to life.

The 8 Phases (A–H) of TOGAF ADM

Here is a quick list, before diving deeper:

Phase	Name	Objective in brief
A	Architecture Vision	Define scope, secure buy-in, sketch a high-level vision
B	Business Architecture	Model how the business must operate to deliver that vision
C	Information Systems Architecture	Define data + application architecture needed
D	Technology Architecture	Define infrastructure, platforms, and technical enablers
E	Opportunities & Solutions	Identify projects/solutions to realize the architectures
F	Migration Planning	Build a roadmap / plan to transition from baseline to target
G	Implementation Governance	Oversee implementation to stay aligned with architecture
H	Architecture Change Management	Manage evolution, respond to new requirements

Preliminary phase 

In the Preliminary Phase, the focus is on establishing the framework and capability needed to support enterprise architecture within the organization. This involves identifying required changes, defining how they will be implemented, and preparing the environment for the ADM cycle.

During this stage, TOGAF is tailored to the organization’s context, core principles are defined, existing capabilities are assessed, and integration with other frameworks or standards is considered. The goal is to ensure that the organization can adopt and sustain the architecture process effectively without being disrupted by future adjustments.

A key output of this phase is the Architecture Work Request, which clearly defines the scope, objectives, tools, and structures required to begin the architecture development process.

Phase A: Architecture Vision

In Phase A, you take the initial “Request for Architecture Work” and use it to clarify who cares, what matters, and why. The goal is to establish a high-level vision, define scope, and get stakeholder approval to move forward. You:

• Identify stakeholders, their concerns, and objectives
• Establish business drivers and constraints
• Propose an initial (sketch) of the target architecture, often a “light version”
• Define scope boundaries, assumptions, risks, and success metrics (KPIs)
• Prepare the Statement of Architecture Work (the go/no-go document)
• Secure formal approval to proceed

This phase is essential to avoid “big jumps in the dark.” It ensures alignment at the outset, so that subsequent phases do not stray into territory nobody asked for. 

Phase B: Business Architecture

The main objective of Phase B is to develop a target business architecture that defines the company’s structure and how the organization must function to realize the vision. Here you define the Baseline (where we are now) and Target (where we want to be) business architecture, and analyze the gaps between them. You cover:

• Business capabilities, organization structure, governance
• Business processes, value streams, roles
• Business rules, policies, and external constraints
• Stakeholder alignment, interfaces, and dependencies

Often you will rely on reference models or industry best practices to accelerate work. The output is a coherent business architecture specification and a gap analysis report. 

Phase C: Information Systems Architecture

Phase C focuses on designing the data and application architectures that work together to support business objectives. Whether you start with data or applications does not matter, the key is ensuring both are integrated and aligned with business goals.

Phase C is typically split or tackled in two parts:

1. Data Architecture: modeling how data is organized, flows, governance, metadata, logical/physical schemas.
2. Application Architecture: defining how software modules, services, APIs, and integrations must be structured to deliver business capabilities.

You again compare baseline to target, and perform gap analysis. You also specify application interfaces, data exchanges, and functional decomposition. The result is an architecture definition for data and applications that aligns with the business architecture. 

Note: The order of data vs application work can vary (you may start with data or application first).

Phase D: Technology Architecture

Technology Architecture defines the technology platforms, infrastructure, and enabling components. Now the architects translate the data + application needs into technology choices: servers, networks, middleware, runtime platforms, deployment, security, etc. You:

• Define baseline and target technology architecture
• Select reference models, toolsets, standards
• Consider performance, scalability, connectivity, availability, and constraints
• Do impact assessments (e.g. on latency, network, location)
• Finalize technical architecture aligned to prior phases

Essentially, this phase “grounds” the solution in realistic infrastructure and ensures the architecture is implementable in the existing or planned tech environment. 

Phase E: Opportunities & Solutions

Phase E focuses on identifying and assessing potential solutions that can meet business requirements. During this stage, architects develop a preliminary architecture roadmap, drawing on the gap analyses and outputs from Phases B, C, and D to outline how the target architecture can be realized. With the architectures defined, now you must find how to bring them to life. Phase E involves:

• Feasibility studies of alternative solution options
• Grouping of architecture building blocks into projects
• Performing value/cost/risk analysis
• Formulating high-level migration strategies
• Drafting an initial architecture roadmap
• Determining implementation constraints and sequencing

Essentially, this phase turns “what we want” into “what we could do next.” 

Phase F: Migration Planning

The goal here is to turn the roadmap into a detailed migration plan. Here you refine the roadmap from Phase E into a workable plan. That means:

• Defining transition architectures (intermediate states)
• Sequencing projects (which to do first, dependencies)
• Estimating cost, risk, and resource needs
• Aligning with change management and project governance
• Finalizing the migration plan and confirming readiness

You do rigorous prioritization and phasing to make deployment achievable.

Phase G: Implementation Governance

This phase oversees the implementation so that the delivered solutions conform to the architectural intent. During execution, the architectural oversight does not end; rather, you monitor, review, and guide:

• Ensure projects implement in accordance with architecture
• Conduct compliance assessments and audits
• Manage deviations, change requests, and remedial actions
• Interface with project management to resolve conflicts

This phase acts as a “guardian” of architecture quality, ensuring the vision is not lost. 

Phase H: Architecture Change Management

Finally, Phase H focuses on keeping the architecture relevant and responsive over time. In an evolving business environment, architecture cannot be static. Phase H ensures:

• Processes exist to identify and assess change requests
• Tools and metrics monitor architecture performance
• Impacts of changes are evaluated and fed back
• The architecture is updated (and new cycles of ADM may begin)

In effect, this phase institutionalizes continuous architectural evolution. 

The Continuous Phase: Requirements Management (Across All Phases)

Although not numbered among A–H, Requirements Management is a continuous activity that runs across all phases. Its role is to:

• Collect, document, prioritize, and manage requirements
• Ensure earlier assumptions remain valid
• Feed requirement changes into relevant phases
• Validate that architectural work remains aligned to them

This ensures the architecture evolves based on valid, traceable requirements rather than whims.

How the Phases Fit Together: Iteration, Feedback & the Architecture Cycle

The ADM is not strictly linear. The eight phases are often revisited, refined, or even “looped back” as new insights or changes arise. Each phase produces work-products, roadmaps, and governance checks that inform subsequent phases or earlier ones. 

Think of it like sculpting, you sketch broadly (A), refine structure (B, C, D), decide how to build (E, F), supervise the build (G), and adjust for reality (H), while always keeping an eye on the original requirements (Requirements Management).

Benefits & Key Pitfalls

Why use the eight-phase (A–H) ADM model?

• It enforces discipline: architects have clear roles, inputs, outputs, and checkpoints
• It aligns architecture work with business goals
• It enforces governance, quality, and consistency
• It enables incremental adoption, you can pilot a cycle rather than try a “big bang”

However, some pitfalls deserve attention:

• Over-engineering: trying to make all phases perfect before delivering anything
• Poor stakeholder engagement: skip buy-in in Phase A and you will pay later
• Rigid adherence without tailoring: ADM must be adapted to your context
• Ignoring change management: implementation will deviate unless governed

Conclusion & Next Steps

The 8 phases (A–H) of TOGAF’s ADM offer a powerful, modular roadmap for building enterprise architectures that deliver strategic value while managing complexity. But the real art comes in tailoring this roadmap to your organization’s maturity, scale, risk tolerance, and domain context.