TOGAF Framework: A Beginner's Introduction (2026)
New to TOGAF? This complete guide covers how the framework works, the ADM cycle, certification structure, and why 80% of Global 50 companies use it.
TOGAF Architecture Framework: Intro
"If you are building an app, you need SOLID. If you are building a Global Corporation, you need TOGAF."
When a company has 50,000 employees, 1,000 applications, and 15 departments each buying software independently, something breaks. Data gets duplicated. Systems can't talk to each other. The CEO announces a new strategy and IT has no idea which of those 1,000 apps needs to change.
TOGAF — The Open Group Architecture Framework — exists to solve exactly this problem. It is the world's most widely adopted enterprise architecture framework, used by 80% of Fortune 50 companies. This guide explains what it is, how it works, and what you need to know to get started.
What is TOGAF?
TOGAF is not a coding framework and it is not a project methodology. It is a process — a repeatable method for designing, planning, implementing, and governing enterprise architecture.
Think of TOGAF as the master blueprint system for an organisation. When a company decides to move to the cloud, merge with another business, or launch in a new country, TOGAF provides the structured approach to answer: what systems need to change, in what order, at what cost, and governed by whom?
The framework was developed by The Open Group, an industry consortium, and first published in 1995. TOGAF 10, the current version, was released in 2022.
The four things TOGAF covers:
- Business Architecture — how the organisation is structured and what business processes it runs
- Data Architecture — what data the organisation owns and how it flows between systems
- Application Architecture — which applications exist and how they interact
- Technology Architecture — the hardware, cloud, and network infrastructure that runs everything
These four domains are not independent — changes to one always affect the others. TOGAF's job is to manage those dependencies before they become expensive problems.
The ADM: The Engine of TOGAF
The Architecture Development Method (ADM) is the core process within TOGAF. It is a cycle of 10 phases that an architecture team works through when designing or changing an enterprise architecture.
The ADM is not a one-time waterfall process. It is iterative — organisations repeat it as their strategy evolves.
For a deeper breakdown of what each phase produces, see the TOGAF ADM phases guide.
The 10 ADM Phases
Preliminary Phase — Before any architecture work begins, the organisation defines its governance structure, architecture principles, and how it will tailor TOGAF. This is setup work that runs once and enables everything else.
Phase A: Architecture Vision — An architecture engagement starts here. The architecture team defines the scope, gets stakeholder buy-in, and produces two key documents: the Architecture Vision and the Statement of Architecture Work. The Statement is the formal authorisation to proceed. See Phase A in detail.
Phase B: Business Architecture — What does the business do today and what should it do in the future? Phase B maps business capabilities, processes, and organisational structures in their current and target states.
Phase C: Information Systems Architecture — Two parallel tracks: the Data Architecture (what data exists and how it flows) and the Application Architecture (which applications support which business processes and how they communicate).
Phase D: Technology Architecture — The physical layer. Which servers, cloud platforms, networks, and middleware support the applications and data defined in Phase C.
Phase E: Opportunities and Solutions — The first planning phase. The team identifies how to bridge the gap between current and target architecture, and begins building the Architecture Roadmap.
Phase F: Migration Planning — The Roadmap becomes a costed, sequenced Implementation and Migration Plan. Work packages are prioritised and phased.
Phase G: Implementation Governance — The architecture team oversees the delivery teams to check that what gets built matches what was designed. Architecture contracts are issued.
Phase H: Architecture Change Management — Once deployed, the architecture enters a maintenance cycle. Change requests are assessed, and when change reaches a sufficient threshold, a new ADM cycle begins.
Requirements Management — Not a numbered phase. It runs continuously throughout all phases, storing and feeding requirements at each gate. Read more about how Requirements Management works.
Architecture Building Blocks
TOGAF encourages architects to think in Architecture Building Blocks (ABBs) — reusable components that can be combined to form larger solutions.
A "Customer Identity Service" is a building block. A "Payment Processing Module" is a building block. Once defined, the same building block can serve multiple applications across the enterprise, eliminating duplicate work.
The Architecture Repository stores these building blocks alongside all other architecture artefacts — decisions, principles, roadmaps, and reference models — so any team in the organisation can reference them. This is what prevents different departments from reinventing the same wheel in incompatible ways.
Governance: How TOGAF Prevents Technical Debt
One of the most common causes of enterprise technical debt is ungoverned decision-making. Without a governance structure, five teams independently solve the same problem five different ways — each using a different database, a different authentication system, a different API format.
TOGAF addresses this with Architecture Governance. Before a project team builds something that touches shared infrastructure or data, they present their design to an Architecture Board. The Board checks:
- Does this comply with the agreed Architecture Principles?
- Does it reuse existing building blocks or introduce unnecessary duplication?
- Does it create integration problems for other systems?
This review process costs time upfront but eliminates the much larger cost of rebuilding incompatible systems later.
TOGAF Certification
TOGAF has two certification levels. Both are administered by The Open Group through Pearson VUE testing centres.
TOGAF Foundation (Level 1) — A closed-book, 40-question multiple-choice exam. It tests knowledge of TOGAF terminology, the ADM structure, and core concepts. Pass mark is 55%.
TOGAF Certified (Level 2) — An open-book, 8-question scenario exam. Candidates are given a business scenario and must choose the most appropriate architectural action. This tests the ability to apply TOGAF, not just recall it. Pass mark is 60%.
Most practising enterprise architects hold TOGAF Certified. Foundation alone is generally sufficient for project managers and technical leads who work alongside architects. For a full comparison, see TOGAF Foundation vs Practitioner.
Is TOGAF Relevant in 2026?
Yes — with adaptations. The original TOGAF process was designed for long, multi-year architecture cycles. Modern organisations run faster than that.
In 2026, most organisations use an iterative approach: short ADM cycles of 3–6 months that align with Agile programme increments. The Preliminary Phase governance structure is set once; individual ADM cycles then run faster and feed directly into delivery sprints.
TOGAF 10, released in 2022, explicitly addresses this — it reframes the framework as a set of modular guidance that organisations apply selectively rather than a rigid end-to-end process.
The result is a framework that scales from large government programmes (where full governance is essential) down to mid-sized organisations running quarterly planning cycles.
A Practical Example: Cloud Migration
Consider a bank migrating its core banking platform to the cloud. Without TOGAF, each department — retail, commercial, and risk — independently selects cloud vendors and contracts with different providers. Integration becomes a three-way negotiation after the fact.
With TOGAF, the engagement begins in Phase A: the architecture team defines scope, documents stakeholder concerns, and produces an Architecture Vision that the board approves. Phase B maps the business capabilities that depend on the core platform. Phase C documents the 140 applications involved and identifies which share data. Phase D defines the target cloud infrastructure — which platforms, in which regions, governed by which contracts.
By Phase E, the team has a sequenced roadmap: which applications move first based on dependency order, regulatory data sovereignty requirements, and cost profile. Phase G then governs the delivery teams: before any team builds a new integration, it presents the design to the Architecture Board to check it complies with the agreed standards.
The result is a migration that stays coherent across 18 months and three delivery teams — because the architecture is managed as a whole, not as isolated projects.
TOGAF in Regulated Industries
TOGAF is particularly valuable in regulated environments — financial services, healthcare, government, and utilities — because regulators increasingly require organisations to demonstrate that they understand and can explain their technology estate.
A financial services regulator might ask: which systems process personal data, where is that data stored, and what controls are in place? A properly maintained Architecture Repository built on TOGAF principles provides those answers. The TOGAF governance structure also creates an audit trail: why was a system chosen, which principles guided the decision, and who approved it.
In government, TOGAF often underpins national digital transformation programmes. Architecture standards defined in the Preliminary Phase become the framework within which dozens of agencies and contractors must operate — preventing the fragmentation that plagued earlier government IT programmes.
The framework also supports compliance reporting. When an audit or inspection requires evidence that security controls are applied consistently across systems, the Architecture Repository provides a single source of documented architecture decisions, traceable from policy through design through implementation. For organisations operating under ISO 27001, DORA, or NHS Digital standards, that traceability is not optional — it is a regulatory requirement.
Where to Go Next
TOGAF is best learned incrementally. Start with the ADM — understanding what each phase produces is the fastest path to understanding how the framework fits together.
From there:
- TOGAF ADM Phases: What Each Phase Produces — the complete phase-by-phase guide
- TOGAF Phase A: Architecture Vision — the phase that starts every architecture engagement
- TOGAF Certification Guide — exam structure, study plan, and pass strategy
Frequently Asked Questions
Q: What is an enterprise architecture framework and why does an organisation need one?
An enterprise architecture framework provides a structured approach for describing, analysing, and planning the structure and operation of an organisation. Without a framework, different teams describe systems in incompatible ways, making it impossible to identify duplication, plan integration, or manage technology risk at scale. TOGAF provides a common language, a repeatable method (the ADM), and a set of tools that allow architects across a large organisation to produce consistent, comparable architecture work.
Q: Is TOGAF only relevant to large enterprises?
No, though it is most commonly adopted by large organisations. TOGAF is explicitly designed to be tailored — smaller organisations can apply a subset of the ADM phases, simplify the deliverables, and skip components that add overhead without value. The Preliminary Phase guidance specifically covers how to scale TOGAF down for organisations that do not need full Architecture Board governance.
Q: How does TOGAF relate to other frameworks like ITIL, COBIT, and SAFe?
TOGAF focuses on architecture — the structure of systems, processes, and technology. ITIL focuses on IT service management. COBIT focuses on IT governance and control. SAFe focuses on agile delivery at scale. These frameworks are complementary: TOGAF describes what the target architecture should look like, ITIL manages the services running on it, COBIT governs the risks and controls, and SAFe delivers the changes to achieve it.
Part of the TOGAF 9.2 Masterclass.