TOGAF Certification Complete Guide: Foundation & Practitioner (2026)

TOGAF (The Open Group Architecture Framework) is the world's most widely adopted enterprise architecture framework. Over 100,000 professionals hold TOGAF certification, and it appears in enterprise architect job descriptions at Fortune 500 companies, government agencies, and global consultancies worldwide.

This pillar guide covers everything you need: what TOGAF is, how the framework works, what each certification level requires, how to study effectively, and what to expect from the exam.

What Is TOGAF?

TOGAF is a framework and methodology for developing, governing, and evolving enterprise architectures. Published by The Open Group, it provides:

• A structured methodology (the ADM) for how to perform architecture work
• A common vocabulary so architects, business leaders, and technologists share the same language
• Templates and guidelines for architecture deliverables
• A governance model for managing architectural decisions and change

TOGAF is not a rigid standard that must be followed exactly — it is a framework designed to be adapted to your organisation's context and needs. The Preliminary Phase exists specifically to tailor TOGAF to your enterprise.

TOGAF Versions

TOGAF 10 restructured the content significantly — the monolithic 900-page document was split into a Standard (the mandatory core) and a Library (optional guidance). The core ADM concepts remain consistent between 9.2 and 10.

Why Get TOGAF Certified?

Career Impact

TOGAF certification is the de facto standard credential for enterprise architects. In 2026:

• Enterprise Architect roles at major consulting firms (Accenture, Deloitte, IBM, Capgemini) routinely list TOGAF as required or preferred
• UK Government Digital Service and US Federal agencies often mandate TOGAF for senior architect roles
• TOGAF-certified architects earn a median premium of 15–25% over non-certified peers in equivalent roles
• The certification demonstrates a shared language — critical when leading multi-team architecture programmes

What TOGAF Gives You

1. Credibility: a universally recognised signal of enterprise architecture knowledge
2. Structure: a proven methodology to navigate complex, multi-stakeholder architecture programmes
3. Vocabulary: precise terms (stakeholder, concern, view, viewpoint, architecture domain) that prevent miscommunication
4. Templates: starting points for architecture deliverables rather than blank pages
5. Governance: a model for Architecture Review Board (ARB) operation and architecture compliance

TOGAF Framework Overview

The TOGAF framework has four components:

1. The Architecture Development Method (ADM)

The ADM is the core of TOGAF — a cyclical, iterative process for developing and evolving enterprise architectures. It has a central phase and eight lettered phases (A through H).

2. ADM Guidelines and Techniques

Supporting guidance for applying the ADM: how to scope architecture work, how to handle iteration, how to adapt the ADM to specific scenarios (security, e-business, service-oriented architecture).

3. Architecture Content Framework

Defines the outputs (deliverables, artefacts) produced during ADM phases. Includes the Content Metamodel — a structured model of architecture concepts and their relationships.

4. Enterprise Continuum and Tools

A classification system for architecture assets, plus guidance on the Architecture Repository — the structured store where all architecture work is kept.

The ADM in Detail

Preliminary Phase

Before the main ADM cycle begins, the Preliminary Phase defines:

• The scope of architecture work (which parts of the enterprise)
• The architecture principles that will govern decisions
• The governance framework (Architecture Review Board, compliance process)
• The tailoring of TOGAF to the organisation

Key outputs: Architecture Principles document, tailored architecture framework, initial Architecture Repository.

Requirements Management (Centre of the ADM Wheel)

Requirements Management is not a phase with a start and end — it is a continuous process at the heart of all ADM phases. It:

• Stores and manages architecture requirements throughout the lifecycle
• Ensures requirements drive the architecture work in each phase
• Handles changes to requirements (fed back into the ADM cycle)

It is positioned at the centre of the ADM wheel to show it feeds into and receives from every phase.

Phase A: Architecture Vision

Objective: Define the scope, identify stakeholders, develop the Architecture Vision, and obtain approval to proceed.

Key activities:

• Identify stakeholders and their concerns
• Define the architecture scope and constraints
• Develop the Statement of Architecture Work (SoW)
• Produce the Architecture Vision (high-level description of the target state)
• Secure approval from the architecture sponsor

Key deliverables: Architecture Vision, Statement of Architecture Work, updated Architecture Repository

Exam tip: Phase A is where you confirm that the architecture work is justified and get sponsor commitment. The Statement of Architecture Work is the formal trigger to begin detailed architecture development.

Phase B: Business Architecture

Objective: Develop the Target Business Architecture based on the Architecture Vision.

Key activities:

• Analyse the current (Baseline) Business Architecture
• Define the Target Business Architecture
• Identify gaps between baseline and target (Gap Analysis)
• Define candidate work packages for the roadmap

Techniques used: Value Chain Analysis, Business Process Modelling, Business Service/Function analysis, Use Case modelling

Key deliverables: Baseline and Target Business Architecture documents, Gap Analysis, Architecture Building Blocks (ABBs)

Exam tip: Phases B, C, and D follow the same pattern — baseline, target, gap analysis, candidate roadmap. Remember that Phase C covers BOTH Data Architecture AND Application Architecture (both are part of the Information Systems Architecture domain).

Phase C: Information Systems Architecture

Phase C is split into two parallel tracks (typically Data first, then Application):

Data Architecture:

• Define the data entities, their relationships, and governance
• Map data to business functions
• Identify data management requirements (MDM, data quality, data lifecycle)

Application Architecture:

• Define the application components and their interactions
• Map applications to business functions
• Identify integration requirements and opportunities for rationalisation

Key deliverables: Data Architecture document, Application Architecture document, Application Interaction Matrix, Gap Analysis for each

Phase D: Technology Architecture

Objective: Define the technology infrastructure (hardware, networking, middleware, platform) that supports the application and data architectures.

Key activities:

• Analyse current technology landscape
• Define Target Technology Architecture (platforms, infrastructure, cloud, security)
• Perform Gap Analysis
• Identify architectural requirements (non-functional: performance, availability, security)

Key deliverables: Technology Architecture document, Technology Portfolio Catalogue, Gap Analysis

Exam tip: Phase D is where cloud strategy, containerisation, and infrastructure-as-code considerations are addressed. The technology architecture must support the applications identified in Phase C.

Phase E: Opportunities and Solutions

Objective: Identify delivery vehicles for the architecture — what projects, programmes, or workstreams will implement the target architecture.

Key activities:

• Review Gap Analyses from B, C, D
• Consolidate gaps into work packages
• Identify transition architectures (intermediate target states)
• Develop the initial Architecture Roadmap
• Identify architecture building blocks (ABBs) and solution building blocks (SBBs)

Key deliverables: Architecture Roadmap (initial), Transition Architecture, Work Package descriptions

Exam tip: Phase E moves from "what should be" to "how to get there." Transition Architectures are formal intermediate states — agreed architectures at defined points in time between the baseline and the full target state.

Phase F: Migration Planning

Objective: Develop a detailed Migration Plan that sequences the implementation projects.

Key activities:

• Prioritise work packages (by business value, risk, dependencies)
• Assign work packages to projects/programmes
• Confirm resource requirements and costs
• Produce the final Architecture Roadmap and Migration Plan
• Handoff to implementation teams

Key deliverables: Architecture Roadmap (final), Migration Plan, Implementation and Migration Plan

Exam tip: Phase F is about planning and sequencing — not executing. Actual implementation happens outside TOGAF (through standard project/programme management). TOGAF governs the architecture; it doesn't manage the projects.

Phase G: Implementation Governance

Objective: Oversee the implementation to ensure conformance with the target architecture.

Key activities:

• Confirm scope of implementation projects
• Issue Architecture Contracts with implementation teams
• Perform Architecture Compliance Reviews
• Manage architecture risks and issues
• Issue Implementation Governance Model

Key deliverables: Architecture Contract, Compliance Assessment, Architecture Compliance Reports

Exam tip: The Architecture Contract is a formal agreement between development teams and the Architecture Board. It defines what must be built, the compliance criteria, and the governance process. Phase G does not control the project — it ensures the architecture is being implemented as specified.

Phase H: Architecture Change Management

Objective: Maintain the architecture as a living asset and manage changes to it.

Key activities:

• Monitor technology, business, and industry developments
• Assess change requests against the current architecture
• Determine whether a change requires a new ADM cycle (major change) or can be handled as a maintenance update (minor change)
• Update the Architecture Repository

Key deliverables: Architecture Updates, Change Requests, new ADM cycle trigger (if significant change is needed)

Exam tip: Phase H is not project change management — it is architecture change management. A change request that requires redesigning a domain architecture triggers a new ADM cycle starting at the appropriate phase.

The Four Architecture Domains

TOGAF defines four architecture domains, collectively called BDAT:

Exam tip: These are addressed in ADM Phases B (Business), C (Data + Application), and D (Technology). The four domains together form the enterprise architecture.

Architecture Content Framework

Deliverables, Artefacts, and Building Blocks

The Content Framework distinguishes between three output types:

• Deliverables: Formal work products contractually agreed with stakeholders. Reviewed and signed off. Examples: Architecture Vision document, Architecture Contract.
• Artefacts: Architectural descriptions — diagrams, matrices, catalogues — contained within deliverables. Examples: Application Interaction Matrix, Technology Portfolio Catalogue.
• Building Blocks: Reusable components of business, IT, or architectural capability.
  • Architecture Building Blocks (ABBs): Technology-agnostic capability components (e.g., "Message Broker")
  • Solution Building Blocks (SBBs): Product or vendor-specific implementations of ABBs (e.g., "IBM MQ")

The Content Metamodel

The Content Metamodel defines the entities (things architectures are made of) and their relationships. Core entities include:

• Actor: a person, organisation, or system that initiates or interacts with processes
• Role: a specific function assumed by an actor
• Business Service: a service provided by a business unit
• Application Service: a service provided by an application component
• Logical Data Component: an encapsulation of data entities
• Technology Component: a specific technology product or platform
• Location: a physical place

The metamodel enables consistent architecture descriptions across domains and supports traceability from business requirements to technology components.

Architecture Repository

The Architecture Repository is the structured store for all architecture work. It has six classes of content:

The Architecture Landscape has three levels:

• Strategic: enterprise-wide, long-horizon, 3–10 year view
• Segment: domain or business unit architectures, 1–3 year view
• Capability: specific solution architectures, within current year

Enterprise Continuum

The Enterprise Continuum classifies architecture assets from generic to specific:

It has two parallel continua:

• Architecture Continuum: abstract models (from Foundation Architecture to Organisation-Specific Architecture)
• Solutions Continuum: physical implementations (from Foundation Solutions to Industry Solutions to Organisation-Specific Solutions)

Architecture Continuum:

1. Foundation Architecture — generic, vendor-neutral (e.g., TOGAF itself, Zachman Framework)
2. Common Systems Architecture — common to many industries (e.g., security architecture, networking)
3. Industry Architecture — specific to a sector (e.g., BIAN for banking, HL7 for healthcare)
4. Organisation-Specific Architecture — tailored to your enterprise

The Enterprise Continuum helps architects leverage existing assets (reuse) rather than creating everything from scratch.

TOGAF Certification Levels

Level 1: TOGAF Foundation

Exam: 40 multiple-choice questions, 60 minutes, closed book, 55% pass mark (22/40)

Tests: Knowledge of TOGAF terminology, structure, and concepts. "What is X?" and "What does Y do?" questions.

Topics covered:

• Basic concepts and terminology (architecture, enterprise architecture, architect)
• ADM phases (what each phase does, key inputs and outputs)
• Architecture Content Framework (deliverables, artefacts, building blocks)
• Enterprise Continuum and Architecture Repository
• TOGAF Reference Models (TRM, III-RM)
• Architecture Governance basics
• Stakeholder management concepts

Study approach: Focus on vocabulary, the ADM phase descriptions, and the Architecture Content Framework distinctions (deliverable vs artefact vs building block).

Level 2: TOGAF Practitioner (formerly TOGAF Certified)

Exam: 8 complex multiple-choice scenario questions, 90 minutes, open book (TOGAF standard permitted), 60% pass mark (5/8)

Tests: Ability to analyse scenarios and apply TOGAF to real-world enterprise architecture situations.

Key difference from Foundation: Foundation = "know what it is." Practitioner = "know how to use it correctly in context."

Exam strategy:

• Read the scenario carefully — identify which ADM phase the scenario is set in
• Understand the role of the person in the scenario (architect, sponsor, stakeholder)
• Eliminate obviously wrong answers — Practitioner distractors are often partially right but subtly wrong
• Use the book strategically — you cannot read it cover to cover during the exam; know where key sections are

Combined Certification Pathway

The Open Group offers a combined exam that tests both Foundation and Practitioner in a single sitting:

• Part 1: 40 Foundation questions (closed book, 60 min)
• Part 2: 8 Practitioner scenarios (open book, 90 min)
• Total: 150 minutes

This is the most efficient pathway if you are prepared for both levels.

Study Plan: 4-Week Foundation Programme

Week 1: Framework Structure and ADM Overview

• Read: TOGAF Standard, Part I (Introduction) and Part II (ADM Overview)
• Focus topics: What is TOGAF, why it matters, the four architecture domains, ADM wheel, Requirements Management
• Practice: Draw the ADM wheel from memory; label each phase with its primary objective
• Quiz yourself: What is the output of Phase A? What triggers Phase H?

Week 2: ADM Phases in Detail

• Read: TOGAF Standard, Part II — each phase (A through H) in detail
• Focus topics: Phase objectives, key inputs, key outputs, phase-specific techniques
• Practice: For each phase, write down: objective, key deliverable, one technique used
• Common exam traps: Phase C covers both Data AND Application; Phase E is Opportunities & Solutions (not Implementation); Phase G is governance (not project management)

Week 3: Architecture Content and Repository

• Read: Architecture Content Framework (Part III), Enterprise Continuum (Part IV)
• Focus topics: Deliverable vs artefact vs building block; ABB vs SBB; Architecture Repository classes; Enterprise Continuum direction (generic to specific)
• Practice: Match each ADM phase to its primary deliverable
• Common exam traps: SBBs are product-specific; ABBs are technology-agnostic

Week 4: Exam Preparation

• Complete practice exam 1 — identify weak areas
• Review weak areas in the TOGAF Standard
• Complete practice exam 2 — target 32/40 (80%) for confidence
• Final review: ADM phases, key deliverables, Architecture Repository classes, Enterprise Continuum
• Day before: light review only — trust your preparation

Common Exam Mistakes to Avoid

Confusing Phase C structure: Phase C covers Information Systems Architecture — which includes BOTH the Data Architecture AND the Application Architecture. Candidates sometimes think Phase C is only Data.

Forgetting Requirements Management: It is not Phase A or a separate step — it is a continuous process at the centre of the ADM. Any question about "throughout the ADM" likely involves Requirements Management.

ABB vs SBB confusion: Architecture Building Blocks are technology-agnostic capability descriptions. Solution Building Blocks are specific products or implementations. ABBs live in the Architecture Continuum; SBBs live in the Solutions Continuum.

Phase E vs Phase F: Phase E = Opportunities & Solutions (identifying what projects to run). Phase F = Migration Planning (sequencing and planning those projects). Phase E finds the work; Phase F plans when to do it.

Phase G is not project management: Phase G governs architecture conformance during implementation. It does not control project timelines, budgets, or team management — that is standard project management.

Architecture Contract: issued in Phase G, not Phase F. Phase F produces the Migration Plan; Phase G converts that into a formal Architecture Contract between the architecture board and the implementation teams.

TOGAF in Practice: What Real Enterprise Architects Do

Understanding how TOGAF maps to day-to-day work helps contextualise exam questions:

Large bank architecture programme example:

1. CTO commissions an architecture review of the payments platform (Phase A trigger)
2. An Architecture Vision document is produced, stakeholders identified, Statement of Architecture Work signed off
3. Business architects map the current payments process and define the target state (Phase B)
4. Data architects define what data must flow through the new system; application architects specify the components (Phase C)
5. Technology architects define cloud infrastructure requirements (Phase D)
6. All gaps are consolidated into a transformation programme of 8 projects (Phase E)
7. The 8 projects are sequenced over 18 months with two transition architectures (Phase F)
8. Architecture Contracts are issued to each project team; quarterly compliance reviews held (Phase G)
9. A new cloud regulation triggers a change request; impact assessment performed; minor update approved without new cycle; but a major technology change triggers Phase D restart (Phase H)

This cycle repeats as the bank evolves. The Architecture Repository accumulates the history of decisions, standards, and approved architectures.

TOGAF Reference Models

TOGAF includes two reference models as examples of Foundation Architectures:

Technical Reference Model (TRM)

A generic platform architecture model showing an application layer sitting on a platform of infrastructure services, with external applications and networks surrounding it. The TRM helps establish the Technology Architecture domain by providing a starting taxonomy of infrastructure services (OS, networking, data management, etc.).

Integrated Information Infrastructure Reference Model (III-RM)

Focused on enabling Boundaryless Information Flow — an Open Group concept of frictionless information sharing across systems, organisations, and communities. The III-RM is particularly relevant for integration architecture and inter-enterprise information exchange.

Exam tip: TRM is about technology infrastructure; III-RM is about information flow across systems. Both are examples of Foundation Architectures in the Architecture Continuum.

Architecture Governance

Architecture Governance is the practice of monitoring, managing, and directing architecture work across the enterprise. Key elements:

Architecture Review Board (ARB):

• Cross-functional group with representation from business and IT
• Reviews proposed architectures for compliance with standards and principles
• Issues architecture waivers (dispensations) when exceptions are justified
• Escalation point for architecture conflicts

Architecture Compliance:

• Assessing whether implementation projects conform to approved architectures
• Compliance levels: Irrelevant, Consistent, Compliant, Conformant, Fully Conformant, Non-Conformant

Dispensation:

• A formal exception granted by the ARB allowing a project to deviate from approved architecture
• Time-limited and conditional — the project must eventually comply or the dispensation must be renewed
• Dispensations are logged in the Governance Log in the Architecture Repository

Architecture Contract:

• The formal agreement between development teams and the architecture governance function
• Defines what must be built, compliance requirements, and review checkpoints
• Signed by both parties; violations trigger escalation to the ARB

After Certification: Career Paths

Enterprise Architect

The primary TOGAF career path. Enterprise architects work across business and IT, defining target architectures for major transformation programmes.

Typical responsibilities:

• Leading architecture workstreams within transformation programmes
• Producing Architecture Vision and domain architecture documents
• Running Architecture Review Boards
• Mentoring solution and application architects

Solution Architect

Solution architects apply enterprise architecture principles to specific solutions. TOGAF provides the framework context; solution architects work within it.

IT Strategy Consultant

TOGAF certification is common in consulting, where architects help clients establish or mature their EA practice.

Chief Architect / Architecture Practice Lead

Senior architects use TOGAF to establish an architecture capability within an organisation — building the practice, setting up the Architecture Repository, training architects, and operating the ARB.

TOGAF 10 vs TOGAF 9.2: Key Differences

The core ADM is unchanged between 9.2 and 10. If you learned 9.2, the concepts transfer directly to 10. The main differences are structural (how content is organised) and some new guidance areas (agile, digital, sustainability).

Exams from 2022 onwards are based on TOGAF Standard version 10 (TOGAF 10). If you are studying now, study TOGAF 10.

Full Learning Path

Work through the complete Topictrick TOGAF Masterclass in sequence:

1. Start with What is TOGAF 9.2? for the big picture
2. Master Core Concepts & Glossary — vocabulary is the foundation
3. Work through each ADM phase article in the series
4. Tackle the Architecture Content Framework and Enterprise Continuum
5. Test yourself with 50 Practice Questions and the Interactive Mock Exam
6. Understand your certification options with Foundation vs Practitioner Comparison

Quick Reference: ADM Phases

TOGAF certification is an investment that pays dividends throughout an enterprise architecture career. The framework gives you a shared language, a proven methodology, and a professional credential that opens doors at the world's largest organisations. Start with the Foundation, build your understanding of the ADM, and the Practitioner level becomes a natural progression.