TOGAF 10 was released in April 2022. For an enterprise architecture framework with a history stretching back to 1995, a new major version is a significant event — and the questions that followed were predictable: Do I need to re-certify? Should my organisation retrain its architects? What actually changed?

The honest answer to all three questions is: it depends on how deeply you understand what changed and why The Open Group made those changes.

This post provides the complete, structured comparison — every significant change between TOGAF 9.2 and TOGAF 10, what each change means in practice, and what it means for architects, organisations, and certification candidates.

The Headline Numbers

Before the detail: TOGAF 9.2 was published in 2018. TOGAF 10 arrived in 2022. The gap was four years — shorter than the 7-year gap between 9.1 (2011) and 9.2 (2018). The version numbering jump from 9.2 directly to 10 signals that The Open Group considered this a more substantial update than the 9.1 to 9.2 transition.

In terms of document size, TOGAF 10 is actually shorter than 9.2. The Open Group deliberately removed deprecated content and reorganised the structure — a trend that began with 9.2 but went significantly further in version 10. The ADM itself (the Architecture Development Method — the process cycle at the heart of TOGAF) is largely unchanged. The major changes are in the surrounding framework elements: what architects do, how they classify what they produce, and how the organisation governs what they deliver.

Change 1 — The Enterprise Metamodel (New in TOGAF 10)

What it is: The Enterprise Metamodel is a formal, standardised schema for architecture artefacts — a defined set of entity types, their attributes, and the relationships between them. It tells architects not just what to produce but how those deliverables should be structured and connected to each other.

What existed before: TOGAF 9.2 had the Architecture Content Framework — which defined deliverables, artefacts, and building blocks, and described what architectural content looked like at a high level. But it did not provide a formal model of how those elements related to each other in a machine-readable or formally structured way.

What changed: TOGAF 10 introduces the Enterprise Metamodel as a distinct and formal component. It specifies entity types (such as Business Actor, Business Service, Application Component, Technology Service) across the business, data, application, and technology domains, and defines how those entities relate to each other.

Why it matters in practice: For architects, the metamodel provides a common vocabulary and structure for architecture content that makes it possible to exchange and compare architecture work across teams and tools in a consistent way. For organisations using architecture modelling tools (like Sparx EA, BiZZdesign, Alfabet), the metamodel provides a reference model that tools can align to. This is the change that has the most significant long-term implications for how enterprise architecture is practised at organisational scale.

Change 2 — The TOGAF Library (Replaces Reference Models)

What existed in 9.2: TOGAF 9.2 included reference models in a dedicated part of the document — the Technical Reference Model (TRM) and the Integrated Information Infrastructure Reference Model (III-RM). These were pre-defined architecture reference models that practitioners could use as starting points.

What changed in 10: TOGAF 10 replaces the reference models section with the TOGAF Library — a broader repository concept that provides guidance, templates, patterns, reference architectures, and other reusable architecture content. The TRM and III-RM are still available but are repositioned as examples of reference library content rather than core framework components.

Why it matters in practice: The Library concept is more flexible and extensible than the fixed reference models of 9.2. Organisations can build their own library content aligned to their specific technology landscape and industry context, rather than relying on the generic TRM which many practitioners found increasingly dated relative to modern cloud-native architectures. The change acknowledges that no single set of reference models can serve the breadth of modern enterprise environments.

Change 3 — Architectural Styles (New Formal Concept)

What existed in 9.2: Architecture patterns and principles existed in 9.2, but there was no formal treatment of architectural styles — the high-level structural approaches (microservices, event-driven, cloud-native, layered, etc.) that fundamentally shape how solutions are designed.

What changed in 10: Architectural styles are introduced as a formal TOGAF concept in version 10. The framework recognises that an organisation's chosen architectural styles — driven by technology strategy, platform choices, and operational requirements — must be explicitly identified and governed, because they shape every architectural decision downstream.

Why it matters in practice: This is the most practically visible change for technology architects. The explicit recognition of architectural styles means TOGAF 10 has a more formal treatment of decisions like "are we a microservices organisation or a monolith-first organisation?" and "do we adopt an event-driven architecture as a standard?" These choices used to sit outside the formal TOGAF scope — in version 10 they are part of the architecture governance conversation.

Change 4 — Certification Restructure

TOGAF 9.2 certification:

  • TOGAF 9 Foundation (Part 1) — core concepts and terminology
  • TOGAF 9 Certified (Part 2) — application of TOGAF in complex scenarios

TOGAF 10 certification:

  • TOGAF Foundation — understanding of TOGAF 10 concepts and terminology
  • TOGAF Practitioner — applying TOGAF 10 in practice

What changed: The names changed (Foundation replaces Part 1, Practitioner replaces Part 2). The content updated to reflect TOGAF 10 — the Enterprise Metamodel, TOGAF Library, and architectural styles appear in the exams. The level of difficulty and structure of the two tiers is broadly comparable.

What stayed the same: The two-tier structure. The fundamental scope of each tier. The fact that Foundation is a prerequisite for Practitioner. The combined certification remains widely recognised by enterprise architecture employers globally.

The important question for existing TOGAF 9 Certified holders: Your TOGAF 9 certification remains valid. The Open Group has not deprecated or retired TOGAF 9 certifications. Whether to pursue TOGAF 10 certification is a professional development decision — not a compliance requirement. Practitioners working with organisations that have adopted TOGAF 10 will benefit from the updated content; those still working in TOGAF 9.2 environments have less immediate need.

Change 5 — Business Architecture Elevated Further

What existed in 9.2: TOGAF 9.2 significantly improved Business Architecture content over 9.1 — it was a major theme of the 9.2 update. The Business Scenarios technique was enhanced, and the Business Architecture chapter was substantially rewritten.

What changed in 10: TOGAF 10 continues and deepens this elevation of Business Architecture. The ADM Phase B (Business Architecture) guidance is more comprehensive. The connection between business strategy, business capabilities, and the downstream architecture domains (data, application, technology) is more explicitly articulated. Business Architecture is increasingly positioned as the entry point and primary driver of the architecture development process, rather than as one of four equal domains.

Why it matters in practice: For architects coming from a technical background, this continues the shift towards expecting enterprise architects to be fluent in business language and business modelling techniques — value streams, business capabilities, business process models — not just technology architecture patterns.

Change 6 — Agile and DevOps Integration

What existed in 9.2: TOGAF 9.2 introduced initial guidance on Agile Architecture — acknowledging that the traditional waterfall-aligned ADM cycle needed to accommodate iterative delivery approaches.

What changed in 10: TOGAF 10 goes further, providing more explicit guidance on how TOGAF is applied in Agile and DevOps environments. The framework acknowledges that architecture work in modern organisations is not sequential or phase-gated in the traditional ADM sense, and provides patterns for applying architectural thinking in sprint-based and continuous delivery contexts.

Why it matters in practice: This is the change that most directly addresses the criticism that TOGAF is a heavyweight, document-heavy framework ill-suited to fast-moving organisations. TOGAF 10 does not resolve that tension entirely — the framework remains comprehensive and structured — but it provides more explicit guidance for architects trying to operate within Agile constraints.

The Complete Comparison Table

Dimension TOGAF 9.2 TOGAF 10
Published April 2018 April 2022
ADM Phases Preliminary + A–H + Requirements Management Unchanged — same phases and structure
Architecture Content Framework ✅ Present ✅ Present — enhanced and aligned to Metamodel
Enterprise Metamodel ❌ Not present ✅ New — formal schema for architecture entities
Reference Models (TRM, III-RM) ✅ Core component ↗️ Repositioned as TOGAF Library examples
TOGAF Library ❌ Not present ✅ New — replaces fixed reference models
Architectural Styles ❌ Not formally defined ✅ New formal concept
Business Architecture Enhanced vs 9.1 Further elevated — more prominent ADM role
Agile guidance Initial guidance Expanded and more explicit
Certification — Level 1 TOGAF 9 Foundation (Part 1) TOGAF Foundation
Certification — Level 2 TOGAF 9 Certified (Part 2) TOGAF Practitioner
Document size ~900 pages Shorter — deprecated content removed
Exam content ADM, Content Framework, Enterprise Continuum Adds Metamodel, Library, Architectural Styles
Backwards compatibility n/a High — ADM unchanged, concepts extended not replaced

What Stayed the Same

It is worth being explicit about what did not change — because misunderstanding this is the most common source of confusion about TOGAF 10.

The ADM cycle is unchanged. Every phase from Preliminary through Phase H, Requirements Management, the inputs and outputs of each phase, the iteration patterns — all unchanged. An architect trained on TOGAF 9.2 who understands the ADM cycle does not need to relearn the process in TOGAF 10.

The Enterprise Continuum is unchanged. The classification of architecture and solutions content from generic to specific remains the same.

The Architecture Repository is unchanged. The six-class content structure remains.

The core governance concepts are unchanged. Architecture Review Boards, Architecture Contracts, compliance assessment — the governance model is the same.

The four architecture domains are unchanged. Business, Data, Application, and Technology Architecture remain the four core domains of TOGAF in version 10.

Which Version Should You Study?

For new certification candidates: Study TOGAF 10. It is the current version, the exams are updated, and it is what employers will reference going forward.

For TOGAF 9.2 Certified practitioners: You do not need to recertify unless your organisation specifically requires it or you want to demonstrate currency with the latest version. Focus your continuing professional development on the three genuinely new areas: the Enterprise Metamodel, architectural styles as a formal concept, and the TOGAF Library model. These are the areas where TOGAF 10 adds value beyond what TOGAF 9.2 provides.

For organisations training their architecture teams: Update your internal TOGAF training material to TOGAF 10 for any new architects joining the function. For existing architects, a targeted gap-fill session on the new framework elements (Metamodel, styles, Library) is more efficient than a full TOGAF 10 Foundation programme.

For organisations deciding whether to adopt TOGAF 10: If you are already using TOGAF 9.2, there is no urgent need to formally "migrate" — the ADM is the same. The new elements of TOGAF 10 can be adopted progressively. The Enterprise Metamodel in particular is worth examining if you use architecture modelling tools or want to improve the consistency and comparability of architecture content across your organisation.

EmergEdge Learning Hub Resources

Both versions are covered in detail in the EmergEdge Learning Hub:

Both guides are free, interactive, and include exam-focused flash cards for certification preparation.

→ Back to the Learning Hub