TOGAF Standard, 10th Edition: TOGAF Standard, 10th Edition – Tutorial (about 60 minutes)

The TOGAF Standard is The Open Group's framework for enterprise architecture: a method and a set of concepts for describing how an organisation fits together today, deciding what it should look like in the future, and steering the change between the two. Enterprise architects, solution architects, business analysts, CIOs and transformation leaders use it to connect business strategy with the processes, data, applications and technology that deliver it. After this tutorial you will be able to explain what the 10th Edition contains, walk through the Architecture Development Method (ADM) phase by phase, use its core vocabulary correctly, set up basic architecture governance, and position TOGAF next to ArchiMate, ISO/IEC/IEEE 42010, Zachman, COBIT, ITIL and agile delivery frameworks.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is the TOGAF Standard, 10th Edition, owned and published by The Open Group. It was first published in April 2022 and replaced the TOGAF Standard, Version 9.2 (2018). In June 2025 The Open Group re-issued the 10th Edition documents as a "2025 Update"; the publication details of the Introduction and Core Concepts document record a second edition dated June 2025 that incorporates the 10th Edition's Technical Corrigendum 1 (a set of corrections and clarifications). The 2025 Update is a maintenance release of the same edition, not an "11th Edition": the method, the core concepts and the certification programme described here all belong to the 10th Edition. At the time of writing we found no announcement of a successor edition on The Open Group's TOGAF pages. Verified 2026-10-29 against The Open Group's TOGAF and certification pages and the publisher's listing of the 2025 Update documents.

Who it is for: engineers, solution architects, business analysts, project and programme managers, IT managers, security and risk staff, and anyone who has been told that "our architecture practice follows TOGAF" and wants to understand what that means. It is also a sound first step before an accredited TOGAF course.

Prerequisites: none. A general idea of how organisations run projects and IT systems helps, but no modelling language, programming or management qualification is assumed.

Learning objectives. After this tutorial you will be able to:

Explain what enterprise architecture is for and why the TOGAF Standard exists.
Describe how the 10th Edition is organised into Fundamental Content and Series Guides, and why it was split that way.
Walk through the phases of the ADM, naming the purpose and typical outputs of each.
Use core terms correctly: stakeholder, concern, view, viewpoint, building block, deliverable, artifact, baseline, target, transition architecture and gap.
Explain the Enterprise Continuum, the Architecture Repository and the role of architecture governance and compliance reviews.
Describe the TOGAF certification paths for people and explain why organisations themselves are not "TOGAF certified".
Compare TOGAF with related frameworks and choose how to combine them.

Lesson 1 – Origins, purpose and scope

Why enterprises need architecture

Any organisation larger than a handful of people accumulates complexity. Business units buy their own applications, customer data is copied into several systems, integrations are built one at a time, and every new project makes local decisions that are sensible on their own but contradictory when added together. After a few years nobody can say with confidence which systems support which business capabilities, what it would cost to change a core process, or which of three overlapping platforms should be retired. Change becomes slow, risky and expensive.

Enterprise architecture (EA) is the discipline that tackles this. It describes the structure of the enterprise as a whole – its capabilities, processes, information, applications and technology, and how they relate – and uses that description to make better decisions about change. Good EA answers questions such as: What do we have today? Where do we want to be in three years? What are the gaps? Which projects close them, in what order, and how do we keep those projects pointing in the same direction?

The word "enterprise" in TOGAF does not only mean a whole corporation. It means any collection of organisations with common goals: a whole company, a government department, a single division, or several partner organisations working together. The scope you choose is called the enterprise for that piece of work.

Where TOGAF comes from

TOGAF began in the mid-1990s. Its first version drew on the Technical Architecture Framework for Information Management (TAFIM) developed for the United States Department of Defense, which was made available to The Open Group. The Open Group – a global, vendor-neutral consortium of customer and supplier organisations – developed it through successive versions: TOGAF 8 in the early 2000s broadened it from technical architecture to enterprise architecture, TOGAF 9 (2009) introduced the content framework and much of today's structure, and versions 9.1 (2011) and 9.2 (2018) refined it. The 10th Edition (2022) kept the method and core ideas but reorganised the documentation radically, and the 2025 Update corrected and clarified it.

The name originally stood for "The Open Group Architecture Framework". Today The Open Group simply calls it the TOGAF Standard, and describes it as an open, industry-consensus framework for enterprise architecture. "Open" here means that it is developed by members through a consensus process and that the documents can be read freely; The Open Group makes the standard available to download free of charge after registration for use inside an organisation, while commercial uses such as delivering training require a licence.

What it covers

TOGAF is a foundational framework: it is generic enough to be applied to any kind of enterprise and any kind of architecture work, from a five-year enterprise-wide strategy to the design of one capability. It covers four classic architecture domains:

Business architecture – strategy, governance, organisation, business capabilities, value streams and key business processes.
Data architecture – the structure of the organisation's logical and physical data assets and how they are managed.
Application architecture – the individual applications, their interactions and their relationship to business processes.
Technology architecture – the software and hardware platforms, networks and infrastructure that host the applications and data.

Data and application architecture together are often called information systems architecture. Security, risk and interoperability are treated as concerns that cut across all four domains rather than as a fifth domain.

TOGAF is not a modelling notation (that is the role of ArchiMate), not a project management method, not a software development process and not a technology product. It tells you what architecture work to do, in what order, what to produce, and how to govern it; it deliberately leaves room for you to choose notations, tools and delivery methods.

Why the 10th Edition was restructured

Version 9.2 was one very large document. Every improvement meant a new release of the whole book, and practical advice for particular situations – agile delivery, digital transformation, security, specific industries – had nowhere natural to go. The 10th Edition separates the stable core (which changes slowly and is the basis for certification) from practical guidance (which can be added and updated more often). The aim is a standard that is easier to navigate, easier to tailor and easier to keep current, with stronger support for agile ways of working and digital transformation.

Lesson 2 – Key concepts and vocabulary

TOGAF has a large vocabulary, and much of the confusion in architecture teams comes from people using the same word for different things. The terms below are the ones you will meet in almost every TOGAF conversation. They are explained in plain words here; the formal definitions are in the Introduction and Core Concepts document.

Architecture – the fundamental structure of a system: its components, how they relate to each other and to their environment, and the principles governing its design and evolution. In TOGAF the word is used both for that structure and for the description of it.
Enterprise architecture – architecture applied to an enterprise (as defined in Lesson 1), covering business, data, application and technology domains.
Architecture Development Method (ADM) – TOGAF's iterative, phased method for developing and managing architecture. It is the heart of the standard.
Stakeholder – an individual, team or organisation with an interest in the outcome of the architecture, such as a chief financial officer, a regulator, an operations team or a customer group.
Concern – an interest a stakeholder has in the architecture, such as cost, performance, security, regulatory compliance or ease of change.
View and viewpoint – a view is a representation of the architecture that addresses particular concerns for particular stakeholders; a viewpoint is the reusable specification (the template and conventions) from which views of that kind are built. The viewpoint is the "how to draw it"; the view is the drawing.
Architecture principle – a general rule that guides architecture decisions, normally written with a name, a statement, a rationale and the implications of following it.
Building block – a reusable package of functionality that meets business needs. An architecture building block (ABB) describes the required capability in a solution-neutral way; a solution building block (SBB) is a specific product, component or service that fulfils it.
Deliverable – a formally reviewed and agreed work product, such as the Architecture Definition Document or the Architecture Roadmap.
Artifact – a more granular piece of architecture description, classified as a catalog (a list of things), a matrix (relationships between things) or a diagram (a picture of things and relationships). Deliverables contain artifacts.
Baseline, target and transition architecture – the baseline describes the current state; the target describes the desired future state; a transition architecture is an intermediate state, a stable plateau reached on the way.
Gap – a difference between baseline and target. Gap analysis is the technique of finding and classifying these differences.
Work package – a set of actions (often a project) that addresses one or more gaps.
Business capability – something the business is able to do, or can obtain from a partner, to reach a specific goal, such as "assess a claim" or "onboard a customer", independent of who does it or which system supports it.
Value stream – the end-to-end set of activities that create a result for a customer or other stakeholder.
Enterprise Continuum – a way of classifying architecture and solution assets from the most generic to the most organisation-specific.
Architecture Repository – the structured store that holds the organisation's architecture assets: models, standards, reference material, governance records and more.
Architecture Board – the cross-organisation body that owns architecture governance, approves architectures and decides on deviations.
Architecture Contract – a joint agreement between architecture and delivery parties that sets out what will be built and the architecture conditions it must respect.

Levels and abstraction

Two further ideas help you avoid "boiling the ocean". First, the Architecture Landscape is described at three levels of breadth and detail: strategic architecture (the whole enterprise, long horizon, used by executives to set direction), segment architecture (a portfolio, business area or programme) and capability architecture (a specific capability increment, detailed enough to guide delivery). Second, TOGAF describes levels of abstraction – from contextual (why) through conceptual and logical to physical (with what) – so that an architect can discuss a problem without jumping straight to products. A logical description says "we need a customer identity store"; a physical one says which product and where it runs.

Enterprise architecture as a service

The 2025 Update of the core concepts presents architecture as a set of services that the architecture function provides to the rest of the enterprise: enterprise support (helping leaders make enterprise-level decisions), design support, development support, eliciting and understanding requirements, architecture planning, and developing the EA practice itself. The point is practical: architects are there to help others decide and deliver, not to produce documents for their own sake.

Lesson 3 – Structure of the standard

The documentation set

The 10th Edition distinguishes the TOGAF Standard from the wider TOGAF Library. The standard itself has two parts:

TOGAF Fundamental Content – the universal concepts and the method that apply to every use of TOGAF. In the 2022 release it was organised into six topic documents: Introduction and Core Concepts; the Architecture Development Method; ADM Techniques; Applying the ADM; Architecture Content; and Enterprise Architecture Capability and Governance. The 2025 Update re-issued the same six documents with corrections, packaged in three published volumes: Introduction and Core Concepts; a volume that combines the ADM, ADM Techniques and Applying the ADM; and a volume that combines Architecture Content with EA Capability and Governance.
TOGAF Series Guides – guidance documents that are also part of the standard and explain how to apply the Fundamental Content in particular situations. Examples include guides on business architecture (capabilities and value streams), enterprise agility and digital transformation, a Leader's Guide for people establishing an architecture capability, an ADM Practitioners' Guide, and guidance on integrating risk and security.

The TOGAF Library is a broader, publicly accessible collection of guides, case studies and white papers published by The Open Group. It supports the standard but is not itself normative.

Figure 1 – The 10th Edition separates stable Fundamental Content from Series Guides, with the TOGAF Library as wider support.

Why does this split matter to you? Because it tells you what is mandatory and what is optional. If your organisation says it "uses TOGAF", it should be using the Fundamental Content concepts and method, tailored. Series Guides are tools you pick when they fit your situation: an agile product organisation will lean on the agility guidance, a bank modernising its core platforms may lean on business architecture and risk guidance. Nobody is expected to apply every guide.

What each Fundamental Content topic covers

Introduction and Core Concepts – what TOGAF is, the vocabulary from Lesson 2, an overview of the ADM, the Enterprise Continuum, the Architecture Repository, the content framework and how to use TOGAF with other frameworks.
Architecture Development Method – the phases of the ADM, each with objectives, inputs, steps and outputs.
ADM Techniques – reusable techniques used inside the phases, such as defining architecture principles, stakeholder management, architecture patterns, gap analysis, interoperability requirements, business transformation readiness assessment, risk management, and evaluating architecture alternatives and trade-offs.
Applying the ADM – how to use the method in real conditions: iterating it, applying it at different levels of the landscape, partitioning the architecture into manageable pieces, and adapting it to different architecture styles.
Architecture Content – the content framework and enterprise metamodel: what deliverables, artifacts and building blocks exist and how the things they describe relate to one another, plus the Enterprise Continuum and the Architecture Repository.
Enterprise Architecture Capability and Governance – how to set up and run an architecture function: organisation, roles and skills, architecture governance, the Architecture Board, Architecture Contracts and compliance reviews.

The ADM at a glance

The ADM is drawn as a cycle of phases around a central requirements management process. There is one preparatory phase and eight lettered phases, A to H. The cycle is a reference sequence, not a strict waterfall: teams iterate within and between phases and tailor the whole thing to their needs.

Figure 2 – The ADM: a preparatory phase, eight phases A–H in a cycle, and requirements management at the centre of all of them.

In outline:

Preliminary prepares the organisation to do architecture: scope, sponsorship, the architecture team, principles, governance and the tailored framework.
Phase A, Architecture Vision, scopes one specific piece of architecture work, identifies its stakeholders and their concerns, sketches the baseline and target at a high level, and gets approval to proceed.
Phases B, C and D develop the business, information systems (data and application) and technology architectures, each with baseline, target and gap analysis.
Phase E, Opportunities and Solutions, consolidates the gaps, groups them into work packages and identifies transition architectures.
Phase F, Migration Planning, turns that into a prioritised, costed implementation and migration plan.
Phase G, Implementation Governance, provides architecture oversight of the projects that build the solution.
Phase H, Architecture Change Management, keeps the architecture current as the business and technology change, and decides when a new cycle is needed.
Requirements Management sits in the middle: requirements are identified, stored, prioritised and changed throughout every phase.

The content framework

The content framework answers "what do we produce?". It defines three kinds of output – deliverables, artifacts and building blocks – and a metamodel that says which kinds of things the architecture describes (actors, roles, business services, processes, data entities, application components, technology components and so on) and how they connect. Using a shared metamodel is what lets an architecture tool answer questions such as "which business capabilities depend on this database?" A key 10th Edition message is that the metamodel is a starting point to be tailored: an organisation should define the enterprise metamodel it actually needs, not model every entity just because the standard lists it.

Lesson 4 – How it works in practice

Preparing: the Preliminary phase and tailoring

The most common reason architecture practices fail is that they start producing diagrams before anyone has agreed why. The Preliminary phase exists to prevent that. Its main activities are to:

define the enterprise in scope and the key drivers for architecture (for example, a regulatory deadline, a merger, a cloud migration or a cost target);
confirm sponsorship and the organisational model for architecture: who the architects are, whom they report to and how they work with portfolio management, security, operations and delivery teams;
agree a first set of architecture principles;
establish governance, including an Architecture Board or an equivalent decision forum;
tailor TOGAF: choose the phases, deliverables, terminology, metamodel and tools that suit the organisation;
set up the Architecture Repository.

Tailoring is not optional decoration; the standard expects it. A twenty-person software company and a national tax authority should not run the ADM in the same way. Tailoring can mean merging phases, dropping deliverables that nobody reads, adopting the organisation's own words, or plugging the ADM into an existing portfolio process.

Starting an engagement: Phase A

Architecture work normally starts with a Request for Architecture Work from a sponsor – for example, "we need to replace the claims platform within two years". Phase A turns that request into an agreed scope. The architect identifies stakeholders and their concerns, confirms business goals and constraints, assesses how ready the organisation is for the change, identifies risks, and sketches the target at a high level. The outputs include the Architecture Vision (a short, persuasive description of the target and its value) and the Statement of Architecture Work, which defines scope, approach, schedule and resources and is signed off by the sponsor. A communications plan, based on stakeholder analysis, says who needs which information and when.

Developing the architectures: Phases B, C and D

Phases B to D follow a common rhythm. For each domain, the team selects the viewpoints and tools to use, describes the baseline (only as much as needed), describes the target, performs gap analysis, defines candidate roadmap components, checks impacts across the rest of the landscape, holds a formal stakeholder review, and records the results in the Architecture Definition Document. Measurable requirements that implementations must meet are captured in the Architecture Requirements Specification.

The order can vary. TOGAF presents business first because the business drives everything else, but in practice data and application work often proceed in parallel, and a technology-led change (for example, exiting a data centre) may start from the technology baseline. The method also allows a baseline-first or target-first approach: in a fast-changing situation teams often describe the target first and document only those parts of the baseline that the change touches.

Gap analysis is the workhorse technique. Teams list the building blocks or services in the baseline and in the target and compare them. Each item is either carried forward unchanged, changed, retired or newly needed. Items that appear in the baseline but not the target need a decision: either they are deliberately eliminated, or someone forgot them – a classic source of nasty surprises in migration.

Planning change: Phases E and F

Phase E looks across all the gaps from B, C and D at once. It consolidates them, considers dependencies and interoperability, decides on approaches (build, buy, reuse, outsource), groups the work into work packages and identifies transition architectures – stable intermediate states that deliver business value on their own. A first Architecture Roadmap emerges here.

Phase F then works with portfolio and project management to finalise the Implementation and Migration Plan: projects are prioritised by business value, cost, risk and dependency, and the plan is aligned with budgets and the organisation's change capacity. Typical Phase F steps are to assign a business value to each work package, estimate resources and timings, prioritise the projects through a cost/benefit and risk assessment, confirm the Architecture Roadmap, and record lessons learned at the end of the cycle. Many organisations also plan delivery around increments of business capability rather than around systems, so that each step is visible to the business.

Governing delivery: Phases G and H

Phase G is where architecture meets delivery. The architects do not build the solution, but they make sure it conforms. Each delivery project agrees an Architecture Contract, and the architecture team runs compliance reviews at agreed points – for example, at design approval and before go-live. Where a project cannot conform, the Architecture Board can grant a time-limited dispensation, require remediation, or decide that the architecture itself should change.

Phase H keeps the architecture alive after delivery. The team monitors technology developments and business changes, assesses change requests, and decides whether a change is simple enough to handle through normal change management, needs an update to the existing architecture, or is big enough to trigger a new ADM cycle with a new Request for Architecture Work.

Figure 3 – Architecture governance: the Board sets direction, contracts bind delivery, and compliance reviews close the loop.

Iteration, levels and agile delivery

Real organisations never run the ADM once from start to finish. The Applying the ADM guidance describes several kinds of iteration that can run in parallel. Roughly: architecture capability iterations (Preliminary and Vision work that creates or improves the practice), architecture development iterations (cycling through business, information systems and technology work), transition planning iterations (opportunities and migration planning) and architecture governance iterations (implementation governance and change management). A strategic architecture might be developed in a long cycle, while capability architectures for individual increments are developed in short cycles inside it.

This is how TOGAF works with agile delivery. Strategic and segment architecture provide direction and guard-rails – principles, target states, key standards and roadmaps – while product teams make detailed design decisions within those guard-rails sprint by sprint. Architects work with the teams, often as members of them, and the ADM phases for a capability increment may take days rather than months. The 10th Edition and its agility guidance make clear that TOGAF does not require big up-front design; it requires that decisions with enterprise-wide effects are made deliberately and visibly.

The Enterprise Continuum and the Architecture Repository

Two structures help an architecture practice reuse what it already has. The Enterprise Continuum classifies assets from generic to specific. Its architecture side runs from foundation architectures (generic structures usable by any organisation), through common systems architectures (patterns for a class of problem, such as security or network management) and industry architectures (patterns for an industry, such as insurance or telecoms) to organisation-specific architectures. Its solutions side mirrors this, from foundation solutions such as general-purpose products to the solutions built for one organisation. Moving to the right means adding specificity; moving to the left means generalising something for reuse.

Figure 4 – The Enterprise Continuum: architectures and solutions classified from generic to specific, with architectures guiding solutions.

The Architecture Repository is where those assets live. The Architecture Content document describes its main areas: the architecture landscape (baseline, target and transition descriptions at strategic, segment and capability levels); the reference library (patterns, templates and reference models); the standards library (standards that solutions must follow); the governance repository (records of decisions, contracts, compliance assessments and dispensations); the architecture requirements repository; and the solutions landscape (the deployed solution building blocks). It also discusses how this repository fits into a wider enterprise repository and links to external reference models and standards. The repository can be a dedicated EA tool, a wiki and a modelling tool, or a combination – TOGAF does not prescribe a product.

Lesson 5 – Assessment, certification and compliance

There is no organisational TOGAF certificate

Unlike management system standards such as ISO 9001 or ISO/IEC 27001, the TOGAF Standard contains no set of auditable requirements for an organisation, and there is no scheme in which a certification body audits a company and certifies it as "TOGAF compliant". When an organisation claims to "follow TOGAF", that is a statement about its method, not an accredited certification. If you need to evaluate such a claim, ask to see the tailored framework, the principles, recent Architecture Definition Documents, the Architecture Board's decisions and evidence that compliance reviews actually happen.

Certification of people

The Open Group runs certification programmes for individuals. For the 10th Edition, the portfolio on The Open Group's TOGAF certification page includes:

TOGAF Enterprise Architecture Foundation – knowledge of the terminology, structure and basic concepts (the Part 1 exam, OGEA-101).
TOGAF Enterprise Architecture Practitioner – the ability to apply the standard to realistic scenarios. Candidates reach it by passing Part 1 and Part 2 (OGEA-102), by a combined exam (OGEA-103), or, if they already hold TOGAF 9 Certified, by a bridge exam (OGEA-10B).
TOGAF Business Architecture Foundation – focused on the business architecture material.
An Applied Practitioner badge – for Practitioner holders who also complete practitioner learning studies with an accredited training provider.
Shorter topic credentials, such as Agile Specialist, Digital Specialist, Enterprise Architecture Leader, Environmentally Sustainable Information Systems Specialist and Integrating Risk and Security.

Note a common misconception: there is no exam called "TOGAF 10 Foundation" or "TOGAF 10 Certified". The TOGAF 9 Foundation and TOGAF 9 Certified credentials, based on Version 9.2, remain listed, and the 10th Edition credentials use the "Enterprise Architecture Foundation/Practitioner" names. Exams can be taken after self-study or after an accredited training course; The Open Group publishes the body of knowledge, the configuration of the programme, and a register of accredited courses.

Certification shows that a person knows (Foundation) or can apply (Practitioner) the standard. It does not by itself make someone an effective architect; experience, domain knowledge and communication skills matter at least as much.

Assessing architecture work: compliance reviews

Inside an organisation, the main form of assessment TOGAF describes is the architecture compliance review: a structured check of a project or solution against the architecture it is supposed to implement. Reviews are scheduled at points where change is still affordable, use checklists derived from principles and standards, and record their findings in the governance repository. TOGAF's governance material describes graded levels of conformance, ranging from irrelevant (the implementation has nothing in common with the specification), through consistent, compliant (it implements only part of the specification, but correctly) and conformant (it implements all of it correctly, plus extra features), to fully conformant – and, separately, non-conformant, where something in the specification is implemented in a way that contradicts it. The value of grading is that "partly compliant" becomes a conversation about which gaps are acceptable, not a pass/fail argument.

When a gap is acceptable for a while, the Architecture Board can issue a dispensation: a time-limited permission to deviate, with conditions and a date for review. Dispensations that are never reviewed quietly become the real architecture, so they must be tracked.

Assessing the practice: maturity

Organisations also assess how mature their architecture practice is. The Preliminary phase includes planning an evaluation of the organisation's enterprise architecture and business-change maturity, so that weak areas (for example, governance or stakeholder engagement) can be found and improved. TOGAF does not impose a single mandatory maturity scale, and there is no certification of maturity. Treat any maturity score as a tool for improvement planning, not a badge.

Lesson 6 – Worked example

Harbourline Insurance (fictional) is a mid-sized insurer with 3,000 employees in four countries. Claims are handled on three different platforms inherited from past acquisitions, customer data is duplicated across them, and a regulator has asked for faster, more transparent claims handling. The board approves a three-year "Digital Claims" transformation and asks the small enterprise architecture team to guide it with TOGAF.

Preliminary – preparing the practice

The chief architect starts by agreeing the basics with the CIO and the chief operating officer. The enterprise in scope is the claims business across all four countries. An Architecture Board is formed with the COO as chair, plus the heads of claims, IT, security, data protection and finance. The team agrees eight architecture principles; one of them is "single source of customer data", with the rationale that duplicated data is behind most complaints and the implication that new systems must read customer data from the master source rather than copy it. TOGAF is tailored: Harbourline will use ArchiMate for diagrams, keep a light Architecture Definition Document per segment, and connect architecture approvals to its existing quarterly portfolio review.

Phase A – the Architecture Vision

The sponsor's Request for Architecture Work asks for one claims platform within three years. In Phase A the architects interview stakeholders – claims handlers, finance, regulators' liaison, the customer-experience team and IT operations – and record their concerns: settlement time, audit trail, cost, data protection and the risk of disrupting claims during migration. The vision describes a target where customers file and track claims online, handlers work on one platform, and every claim decision is traceable. Success measures are agreed: average settlement time cut by a third and one customer record per person. The Statement of Architecture Work is signed by the COO.

Phases B, C and D – business, information systems and technology

In Phase B the team builds a business capability map for claims ("register claim", "assess claim", "detect fraud", "settle claim", "recover costs") and a value stream from first notification to payment. Comparing baseline and target shows gaps: fraud detection is manual in two countries, and there is no capability for customers to track a claim. In Phase C the data architecture identifies "customer", "policy", "claim" and "payment" as core entities and a master source for each; the application architecture shows that two of the three claims platforms can be retired and that a customer portal and a document service are new. Gap analysis also reveals that one of the old platforms produces a regulatory report that nobody had listed – an unintended omission that would have been lost if the platform had simply been switched off. In Phase D the technology architecture places the new platform on the group's cloud landing zone, with integration through the existing API gateway and an identity service for customers.

Phases E and F – roadmap and migration plan

Phase E consolidates the gaps into five work packages: customer master data, claims platform rollout, customer portal, fraud analytics and decommissioning. Because a "big bang" switch is too risky, the team defines two transition architectures.

Figure 5 – Harbourline's roadmap moves from baseline to target through two transition architectures, each delivered by work packages.

In Phase F the architects and the portfolio office estimate costs and benefits, sequence the work around the insurance renewal season, and agree the Implementation and Migration Plan with the board. Each transition must deliver value on its own: Transition 1 already reduces duplicate customer records even before the new platform arrives.

Phase G – governing delivery

Each delivery team signs an Architecture Contract. At a compliance review the portal team proposes keeping its own copy of customer addresses to improve page speed. The Board treats this as a deviation from the single-source principle; rather than refusing outright, it grants a six-month dispensation on condition that the copy is a read-only cache refreshed from the master, and records the decision in the governance repository. The review after six months confirms that the cache works and the dispensation is closed.

Phase H – managing change

Eighteen months in, a new regulation requires claims decisions made with automated models to be explainable. The architects assess the change: it affects the fraud analytics work package and the audit capability, but not the overall target. They update the target architecture and the Architecture Requirements Specification rather than starting a full new cycle. A year later, when Harbourline acquires another insurer, the change is large enough that the Board issues a new Request for Architecture Work, and the ADM begins again from Phase A, reusing principles and building blocks from the repository.

What the example shows

Harbourline did not produce every artifact in the standard. It tailored the framework, focused on the stakeholders' concerns, used gap analysis to find a hidden dependency, planned stable transitions rather than one leap, and used governance to make a pragmatic, recorded decision rather than an argument. That is what using TOGAF well looks like.

Lesson 7 – Relationship to other standards and frameworks

TOGAF is designed to be used alongside other frameworks. The 10th Edition explicitly discusses using it with other frameworks and with different architecture styles. The most common combinations are summarised below.

Framework or standard	What it is	How it relates to TOGAF
ArchiMate (The Open Group)	A modelling language for enterprise architecture with defined elements, relationships and viewpoints.	Complementary: TOGAF says what to describe and when; ArchiMate gives a standard notation to draw it. Its layers map closely to TOGAF's domains.
ISO/IEC/IEEE 42010	An international standard for architecture description: stakeholders, concerns, viewpoints, views and model kinds.	TOGAF's use of stakeholders, concerns, views and viewpoints is aligned with these concepts; 42010 is about describing architectures, not developing them.
Zachman Framework	An ontology that classifies architecture descriptions in a grid of perspectives (rows) and interrogatives (what, how, where, who, when, why).	A classification scheme rather than a method; some organisations use Zachman to check completeness and TOGAF to run the work.
COBIT (ISACA)	A framework for governance and management of enterprise information and technology.	COBIT has an objective for managed enterprise architecture; TOGAF provides the method that can meet it, while COBIT frames the wider governance system.
ITIL 4 and IT4IT	ITIL is guidance for IT service management; IT4IT is The Open Group reference architecture for managing the business of IT.	TOGAF designs the target; service management runs and changes it. IT4IT can serve as a reference architecture for the IT function within the Enterprise Continuum.
SAFe and other agile frameworks	Frameworks for scaling agile delivery across teams and portfolios.	Agile frameworks organise delivery; TOGAF provides enterprise-level direction, guard-rails and roadmaps that agile teams work within.
PRINCE2, MSP and PMI standards	Methods and standards for project, programme and portfolio management.	Phases E, F and G hand architecture outputs to project and programme management and govern what those projects deliver.

Two points are worth remembering. First, frameworks rarely compete head to head: they answer different questions (how to describe, how to develop, how to govern, how to deliver, how to operate). Second, combining them requires a deliberate mapping – who owns the roadmap, which board approves what, which artifacts are shared – or you end up with duplicate governance forums and conflicting templates. The Preliminary phase is the right place to decide this mapping.

Common pitfalls and best practices

Pitfalls

Treating TOGAF as a documentation checklist. Teams try to produce every deliverable and artifact, spend months on documents nobody reads, and lose the trust of delivery teams.
Skipping the Preliminary phase. Starting with diagrams before agreeing scope, sponsorship, principles and governance leads to architecture that has no authority and no audience.
Documenting the whole baseline in detail. Describing every current system "for completeness" consumes the budget before any target is defined.
Ivory-tower architecture. Architects design targets without involving the people who will build and run them, so the architecture is ignored in delivery.
Governance without teeth – or with too many teeth. Either compliance reviews never happen, or every small decision waits for a monthly board, pushing teams to work around architecture.
Confusing the method with the notation or the tool. Buying an EA tool or adopting ArchiMate is not the same as having an architecture practice.

Best practices

Tailor deliberately and write it down. Decide which phases, deliverables and terms you will use, and record the tailored framework in the repository.
Start from stakeholder concerns. Build only the views that answer real questions from real stakeholders, and choose viewpoints accordingly.
Use the three levels of the landscape. Keep strategic architecture light and long-term, segment architecture for portfolios, and detailed capability architecture only where delivery needs it.
Plan in stable transitions. Use transition architectures that each deliver business value, so a programme can pause safely.
Make governance proportionate. Let teams decide within clear guard-rails, reserve the Board for enterprise-wide decisions, and track every dispensation to closure.
Measure value. Tie architecture work to business outcomes agreed in Phase A, and report progress against them.

Summary and key takeaways

The TOGAF Standard, 10th Edition (2022, with a 2025 Update incorporating Technical Corrigendum 1) is The Open Group's open, consensus framework for enterprise architecture.
It is split into stable Fundamental Content and situation-specific Series Guides, supported by the non-normative TOGAF Library.
The ADM – Preliminary, phases A to H and central requirements management – is an iterative method for developing and governing architecture, meant to be tailored.
Architecture is described through stakeholder-driven views, using deliverables, artifacts (catalogs, matrices, diagrams) and building blocks (ABBs and SBBs) within a tailored metamodel.
Baseline, target, gap analysis and transition architectures turn a vision into a realistic roadmap and migration plan.
The Enterprise Continuum and Architecture Repository support reuse; the Architecture Board, contracts and compliance reviews provide governance.
Organisations are not certified against TOGAF; individuals can earn Foundation, Practitioner and specialist credentials from The Open Group.
TOGAF works best combined with a notation (ArchiMate), governance (COBIT), service management and agile delivery frameworks, with a clear mapping between them.

Reflection questions

Think of a recent project in your organisation that created a duplicate system or data store. At which ADM phase, and with which principle or governance step, could that have been caught?
Which three stakeholder groups in your organisation would have the strongest concerns about a major platform change, and which views would you prepare for each of them?
If you had to tailor the ADM for a product organisation that ships software every week, which phases would you run quickly and repeatedly, and which would you keep at a slower, enterprise-wide rhythm?
Pick one current-state system you know well. How would you describe it as an architecture building block and as a solution building block, and why does the distinction matter when you plan its replacement?
Your Architecture Board has granted a dozen dispensations in the past year and reviewed none of them. What would you change in your governance process, and how would you show the change worked?