TOGAF 10 structure and what changed

The Open Group publication page is the authority here. It identifies The TOGAF Standard, 10th Edition as the current core standard, published 19 May 2025, with Technical Corrigendum 1 applied. It also states explicitly that the standard is divided into the TOGAF Fundamental Content and the TOGAF Series Guides.

That matters because it tells you how the standard now wants to be used. The core is the durable spine. The guides are the official way to configure that spine for the problem in front of you. And the TOGAF Library provides supporting material that sits alongside both layers.

As of April 2026, the working baseline used in this course is the 10th Edition with Technical Corrigendum 1 applied. When new corrigenda or guide revisions are published, the course will note the differences. But the structural principle (core plus guides plus library) is stable and unlikely to change.

TOGAF 9.2 was a monolithic document. The ADM, the techniques, the content framework, and the governance material all lived in a single publication. There was no formal separation between the parts that were intended to be stable for years and the parts that were expected to evolve more quickly as new topics (digital, agile, data, security) matured.

TOGAF 10 introduced a structural change that can be stated in five points:

1. The core standard was separated from guidance that changes more often. This is the defining change. The six Fundamental Content volumes became the clearly identified long-life backbone, while practical and topical guidance was moved to separately published Series Guides.
2. The six Fundamental Content volumes became the durable base. Each volume has a clear purpose: concepts, the ADM, techniques, ADM application, content framework, and governance. You know where to look for the canonical answer.
3. Series Guides became the main vehicle for practical and context-specific depth. Topics like business architecture, digital enterprise, enterprise agility, information mapping, and risk and security each got their own guide that can be updated independently of the core.
4. The TOGAF Library became the supporting layer. Helpful aids, reference cards, pocket guides, and companion material now have a defined home that is clearly distinct from the core and the guides.
5. Certification was separated more clearly from the framework itself. The certification programme (Foundation, Practitioner, Business Architecture Foundation) tests selected portions of the body of knowledge. It is useful for structured learning, but it is not the boundary of what TOGAF contains.

The result is a more modular standard that is easier to navigate, easier to teach, easier to adopt selectively, and easier to extend without destabilising the core method.

Module 1 introduced these volumes. This section teaches each one individually so you know exactly what is inside each volume and when to open it.

C220 Part 0: Introduction and Core Concepts

Part 0 is the conceptual front door. It defines what enterprise architecture is and establishes the vocabulary that the rest of the standard uses. Specifically, Part 0 contains:

• The definition and scope of enterprise architecture
• The four architecture domains: business, data, application, and technology
• Architecture principles and how they guide decisions
• The enterprise continuum (a classification from generic to organisation-specific)
• Viewpoints and views (how different stakeholders see the architecture)
• Architecture services (what the EA capability does for the enterprise)
• Agility considerations (how architecture supports rather than blocks adaptive delivery)
• Risk considerations (how architecture integrates risk thinking)

When to open it: when you are new to the standard, when you need to ground a conversation in first principles, or when a discussion about architecture scope, domains, or principles needs a canonical reference.

C220 Part 1: Architecture Development Method

Part 1 contains the ADM, the step-by-step process TOGAF uses to create and manage enterprise architecture. The ADM is the most recognised part of TOGAF, represented by the familiar wheel diagram. Part 1 covers each phase:

• Preliminary Phase: setting up the architecture capability, agreeing principles, choosing tools
• Phase A: Architecture Vision: creating the high-level picture, securing stakeholder buy-in
• Phase B: Business Architecture: mapping how the business works and should work
• Phase C: Information Systems Architectures: data architecture and application architecture
• Phase D: Technology Architecture: infrastructure, platforms, networks
• Phase E: Opportunities and Solutions: identifying work packages and projects
• Phase F: Migration Planning: creating the detailed roadmap
• Phase G: Implementation Governance: overseeing the build
• Phase H: Architecture Change Management: monitoring for triggers that start a new cycle
• Requirements Management: the continuous process at the centre of the wheel

When to open it: when you are planning or running an ADM engagement, when you need to know the inputs, steps, and outputs of a specific phase, or when you need to explain the architecture lifecycle to a sponsor.

C220 Part 2: ADM Techniques

Part 2 provides disciplined techniques for handling specific challenges that arise during the ADM. These techniques are used alongside the phases, not instead of them. Part 2 covers:

• Architecture principles (how to define, document, and apply them)
• Stakeholder management (identifying, classifying, and engaging stakeholders)
• Architecture patterns (proven, repeatable solutions to common design problems)
• Business scenarios (discovering requirements through structured storytelling)
• Gap analysis (comparing baseline to target to identify what must change)
• Migration planning (sequencing transitions and managing dependencies)
• Interoperability assessment
• Readiness assessment (evaluating whether the organisation is ready for change)
• Risk management (integrating risk into architecture decisions)
• Capability-based planning (linking strategy to execution through capabilities)

When to open it: when you hit a specific challenge during a phase and need a disciplined approach. For example, when Phase A needs a business scenario to frame the problem, or when Phase E needs gap analysis to identify work packages.

C220 Part 3: Applying the ADM

Part 3 addresses what happens when the ideal ADM cycle meets enterprise reality. In practice, the ADM is almost never run as a single linear pass from Preliminary through to Phase H. Part 3 covers:

• Iteration and levels (how to run the ADM in cycles, at different levels of detail)
• The architecture landscape (how strategic, segment, and capability architectures relate)
• Security architecture and the ADM (how security integrates into each phase)
• Architecture partitioning (how large enterprises divide architecture work across teams)

When to open it: when you need to adapt the ADM to your enterprise's size, complexity, or delivery model. If you are running architecture in a large organisation with multiple teams, Part 3 explains how to partition and coordinate the work.

C220 Part 4: Architecture Content

Part 4 defines what architecture work should produce and how all the outputs relate to each other. This is the volume that answers the question "what does the architecture team actually deliver?" Part 4 covers:

• Content framework (the organising structure for all outputs)
• Deliverables (formally reviewed and signed-off work products)
• Artefacts (specific documents, diagrams, catalogues, and matrices)
• Viewpoints and views (how different stakeholders see the architecture)
• Building blocks (reusable components: ABBs and SBBs)
• The architecture repository (central storage for all architecture knowledge)
• The content metamodel (the logical structure that defines how all content is organised)

When to open it: when you need to understand what a phase should produce, when you need to design a repository, or when someone asks how deliverables, artefacts, and building blocks differ.

C220 Part 5: Enterprise Architecture Capability and Governance

Part 5 covers the sustaining mechanism. It answers the question "how does the architecture capability stay alive and useful after the first design pass?" Part 5 covers:

• Establishing an EA capability (people, processes, tools, organisation)
• Architecture governance (practices and structures that ensure decisions are made properly)
• Architecture Board behaviour (how the cross-organisation oversight body operates)
• Compliance reviews (checking that implementations match the approved design)
• Architecture contracts (formal agreements between architecture and delivery teams)
• Waivers (formal exceptions when projects cannot fully comply)
• Architecture maturity assessment (measuring and improving the capability over time)

When to open it: when you need to set up or improve the architecture capability, when you need to design a governance model, or when you need to understand how compliance and waivers work.

A Series Guide is an official publication by The Open Group that explains how to use the TOGAF core in a specific context. It is not a replacement for the core. It is an extension that adds practical depth for a particular topic, domain, or delivery approach.

The relationship works like this: the Fundamental Content defines the operating model (concepts, ADM, techniques, content, governance). A Series Guide takes that operating model and shows you how to configure it for a specific problem. For example, the core ADM defines Phase B (Business Architecture) in general terms. The Business Capabilities guide (G211) adds detailed techniques for mapping and assessing capabilities. The core defines gap analysis as a technique. The guide shows you how to apply it specifically to capability maturity.

Series Guides carry authority within their scope. They are not optional extras or marketing material. But they are designed to be selected based on the problem at hand. You do not read all 26 guides before starting work. You read the core, then reach for the guide that fits the problem.

The guide publication codes follow a pattern. Each has a "G" prefix followed by a three-character identifier. The full catalogue is available on The Open Group publications page, but the grouping below is more useful for navigation than the raw list.

The following is the full set of TOGAF Series Guides grouped by the problem domain they address. The grouping is practical, not official, but it makes navigation easier than reading by publication code.

Leadership and practice (2 guides)

1. G184: Leader's Guide to Establishing and Evolving an EA Capability
2. G186: Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM

These two guides are the starting pair for any organisation setting up or repairing its architecture capability. G184 addresses the leadership and organisational design questions. G186 addresses the day-to-day practitioner workflow.

Business architecture (6 guides)

1. G176: Business Scenarios
2. G178: Value Streams
3. G18A: Business Models
4. G206: Organisation Mapping
5. G211: Business Capabilities
6. G233: Business Capability Planning

These guides deepen the business layer beyond what Part 1 Phase B provides. They let TOGAF shape strategy, operating model, capability maturity, value delivery, and investment planning.

Digital and agile delivery (3 guides)

1. G210: Agile Architecture Sprints
2. G217: Using the TOGAF Standard in the Digital Enterprise
3. G20F: Enterprise Agility

These guides exist because teams frequently assume TOGAF is incompatible with agile delivery or digital operating models. They show how the core method adapts to sprint-based work, continuous delivery, and platform thinking.

Information and data architecture (4 guides)

1. G190: Information Mapping
2. G21B: Customer Master Data
3. G234: Metadata Management
4. G238: Business Intelligence and Analytics

These guides provide the depth that Phase C needs when the architecture problem involves serious data work: master data quality, metadata standards, information flows, and analytics architecture.

Security and risk (1 guide)

1. G152: Integrating Risk and Security with TOGAF Enterprise Architecture

This guide addresses how to weave risk and security into architecture decisions rather than treating them as a separate workstream.

Specialist topics (5 guides)

1. G21D: Government Reference Model
2. G21I: Microservices
3. G242: Sustainable Information Systems
4. G248: Selecting Building Blocks
5. G22A: Architecture Project Management

These guides let the core method carry public-sector, microservices, sustainability, building-block selection, and project-management concerns more credibly.

Additional guides (5 guides)

1. G19C: Architecture Skills Framework
2. G19F: Architecture Compliance Reviews
3. G1AC: Enterprise Architecture Capability Maturity
4. G21F: Enterprise Architecture at Large
5. G240: Architecture and Emerging Technologies

These cover skills, compliance review processes, maturity assessment, large-scale architecture, and the integration of emerging technologies.

The TOGAF Library is the third layer of the publishing model. It is where supporting material lives: reference cards, pocket guides, templates, practical accelerators, and related official material that supports the main standard rather than replaces it.

The Library is official. It is not a dumping ground for afterthoughts. But it carries less authority than the Fundamental Content or the Series Guides. The practical rule is: use Library material after you understand whether the answer you need is normative (from the core), contextual (from a guide), or supportive (from the Library).

The Library also includes the BOK Guide (publication code 02.1), a navigation document that maps the entire TOGAF publication ecosystem. Think of the BOK Guide as the table of contents for the whole body of knowledge. It is particularly useful when you know what topic you need but are not sure which publication code to look for.

Six practical consequences flow from the structural change:

1. It stops the standard from being intimidating. A single 600-page document with no clear hierarchy overwhelms beginners. Six volumes with distinct purposes, plus a guide layer you pick up when needed, is navigable.
2. It lets newer topics mature without destabilising the core. When The Open Group publishes a new guide on sustainability or emerging technologies, the core ADM does not change. The guide extends the method for a new context.
3. It makes the teaching sequence cleaner. You teach the backbone first (this is what the operating model is), then add depth only where it changes judgement (this is how the operating model adapts to your problem).
4. It helps enterprises tailor their adoption. A team working on business architecture reaches for the business capability guides. A team working on digital transformation reaches for the digital enterprise guide. Neither team needs to read the entire publication set.
5. It reduces exam-as-framework confusion. When the standard is monolithic, people mistake the certification syllabus for the boundary of what TOGAF is. When the structure is explicit, it is clear that certification tests selected portions of a much broader body of knowledge.
6. It provides clear authority levels. Practitioners know that a claim in the Fundamental Content outranks a recommendation in a Series Guide, which in turn outranks a suggestion in Library material. This prevents the confusion caused by treating all documents as equally primary.

These five errors appear frequently in teams encountering TOGAF 10 for the first time. Correcting them early prevents months of confusion.

• TOGAF 10 is one PDF and one wheel. It is not. It is a structured set of official layers with different authority levels and different rates of change. The ADM wheel is one diagram in one part of one of six volumes.
• Series Guides are optional trivia. They are not. They are official publications and often where the practical depth lives. A team that ignores the business capability guide while running Phase B is ignoring the configurable layer that makes the core practical.
• The Library is a dumping ground. It is part of the official support ecosystem, not a collection of afterthoughts. Reference cards, pocket guides, and the BOK Guide live here.
• A modular standard is a weaker standard. The opposite is true. Clearer separation between durable backbone and configurable depth makes the standard more usable, not less authoritative. The core does not lose authority because guides exist alongside it.
• You must read everything before starting. The modular structure exists precisely so you can read selectively. Start with the core. Add the guide that fits the problem. Read the Library material when you need practical aids. That is the intended sequence.

The course uses the TOGAF 10 structure directly. The core standard gives the backbone for phases, concepts, techniques, repository logic, and capability design. The Series Guides deepen the exact points where the London case would otherwise become thin.

Here is why the modular structure matters for London Grid specifically. The fictional company faces problems that span multiple guide domains simultaneously:

• Business architecture depth: The connections reform and DSO transition require business capability mapping, value stream analysis, and business scenario work. Stage 2 of this course uses G211, G178, and G176 to frame the problem correctly.
• Information architecture depth: The LTDS publication obligation and the asset register problem require information mapping, metadata management, and analytics architecture. Stage 4 uses G190, G234, and G238 where the data-authority problem needs depth.
• Agility and governance depth: London Grid delivery teams work in sprints, but governance expectations are heavy because of regulatory requirements. Stages 6 and 7 use G20F, G210, G22A, G19F, and G1AC where delivery and governance judgement becomes the hard part.
• Security depth: The SCADA and OT security challenge requires architecture-integrated security thinking. G152 informs how security concerns thread through every ADM phase rather than sitting in a separate workstream.

That is why this course does not have a detached "Series Guides" section. Each later stage brings in the guide only when the architecture problem needs it. You learn the guide in context, not in isolation.

If London Grid were starting its TOGAF adoption today, the architecture lead would begin with Part 0 and Part 1 (to understand concepts and the ADM), then immediately reach for G211 (Business Capabilities) and G190 (Information Mapping) because those are the two domains where the enterprise pressure is most acute. G184 (Leader's Guide) would be needed in parallel to design the architecture capability itself. The remaining guides would be pulled in as each stage of the transformation demanded deeper treatment.