What is TOGAF? Framework, ADM Phases, Domains & Metamodel Explained

In short: TOGAF (The Open Group Architecture Framework) is the de-facto standard framework for enterprise architecture. Its heart is the ADM (Architecture Development Method) – an iterative cycle that takes an organisation methodically from its current to its target architecture, with governance built in. TOGAF answers the question “How do we do enterprise architecture systematically?” This article explains what TOGAF is, how the ADM works, what certification means, and – from our experience in real Portamus client projects – when TOGAF is the right choice and when it needs tailoring.

Key takeaways

• TOGAF is a framework — a set of method and concepts maintained by The Open Group — and the world’s most widely adopted EA framework.
• Its core is the ADM (Architecture Development Method) — the iterative cycle of phases A–H (plus Preliminary) around continuous Requirements Management.
• TOGAF defines four architecture domains — Business, Data, Application, and Technology (IT) Architecture — plus a metamodel (Architecture Principles, Views, Building Blocks).
• TOGAF describes the process; it deliberately prescribes no modelling notation – which is where a modelling language like ArchiMate fits in.
• TOGAF is adaptable (tailoring): the ADM should be tailored to the organisation, not applied dogmatically.
• Certification (Foundation, Practitioner) proves knowledge of the standard; results depend on experienced application.
• And if you don’t want to drive TOGAF yourself: Portamus is TOGAF®-certified and applies the ADM in EA engagements — see the Portamus TOGAF portfolio.

What is TOGAF?

TOGAF is the de-facto standard framework for enterprise architecture, maintained by The Open Group. It provides a structured, repeatable approach to planning, designing, governing and evolving the architecture of an organisation across business and IT. Rather than a rigid rulebook, TOGAF is a method plus a supporting toolkit that architecture teams tailor to their context.

TOGAF provides, among other things:

• the ADM as the delivery method (Preliminary, phases A–H, Requirements Management),
• a Content Framework defining which deliverables and artefacts are produced in each phase,
• a metamodel: Architecture Principles, Views, and Building Blocks as the common vocabulary of architecture work,
• an Enterprise Continuum and reference models for classifying and reusing architecture assets,
• governance and stakeholder concepts to keep architecture decisions accountable.

What TOGAF deliberately does not prescribe is a concrete notation for the models themselves – which is exactly where a modelling language such as ArchiMate comes in. We compare the two in TOGAF vs. ArchiMate.

The ADM: the heart of TOGAF

The Architecture Development Method (ADM) is what most people mean when they talk about “doing TOGAF”. It is an iterative cycle – not a one-off waterfall – that continuously evolves the architecture:

At the centre sits Requirements Management, which feeds and is fed by every phase. In our client projects this central role of requirements is decisive: it keeps the architecture anchored to what the business actually needs, cycle after cycle.

Rule of thumb: TOGAF’s ADM tells you which steps to take to move from today’s architecture to a defensible target – and how to govern that journey.

TOGAF certification

The Open Group offers a formal certification programme, typically in two levels:

• TOGAF Foundation – knowledge of the terminology, structure and core concepts.
• TOGAF Practitioner – the ability to apply the ADM and concepts in practice.

For individuals – architects, consultants, project leads – certification is a widely recognised credential and a shared vocabulary. For organisations, the more important question is competent, tailored application. In our experience the same standard delivers very different results depending on who applies it and how well they adapt it – which is why we treat certification as a foundation, not a guarantee.

When TOGAF is the right choice

From our advisory practice, TOGAF fits especially well when:

• you need a structured, governable process for enterprise architecture, not ad-hoc diagrams;
• you are driving a major transformation (cloud, ERP replacement, consolidation, AI adoption) and need a defensible roadmap;
• multiple teams must work to a common method and vocabulary;
• you want architecture to be a continuous steering capability, not a one-off document.

And where it needs care:

• TOGAF is not a modelling notation – pair it with ArchiMate for consistent models;
• applied by rote, the full ADM can feel heavyweight – tailoring is mandatory, especially in mid-sized organisations. In our projects we consistently scope the ADM to the organisation’s size and maturity.

Common misconceptions

• “TOGAF is too heavyweight for us.” → TOGAF is adaptable; the ADM is meant to be tailored. Right-sized, it works for the mid-market too.
• “TOGAF is a modelling tool.” → No. TOGAF is a method; it prescribes no notation. Use ArchiMate for the models.
• “Certification equals capability.” → Certification proves knowledge of the standard; delivering value depends on experienced, tailored application.
• “TOGAF and Agile don’t mix.” → They do. The ADM is iterative by design and integrates well with agile delivery when scoped sensibly.

The TOGAF metamodel: Principles, Views, Building Blocks

Beyond the ADM, TOGAF provides a metamodel — the meta-view of what architecture work consists of and what happens in each phase:

• Architecture Principles: binding design principles that steer architecture decisions and protect against arbitrary choices. Practice tip: always formulate principles as name + statement + rationale — without the rationale the slogan stays toothless.
• Views: perspectives on the same architecture work — e.g. business, data, application or technology views per stakeholder group, instead of “one giant diagram for everyone”.
• Building Blocks: reusable units — Architecture Building Blocks (ABBs) as conceptual blocks and Solution Building Blocks (SBBs) as concrete realisations (tools, products, services). From practice: a well-maintained SBB catalogue from earlier projects noticeably accelerates every new roadmap.

The metamodel is the reason TOGAF is more than “eight boxes in a circle”: it gives the ADM its vocabulary, making architecture work comparable and verifiable across teams and projects. Concrete rendering of the metamodel’s views is typically done with a modelling language such as ArchiMate.

TOGAF across the architecture domains: data and IT architecture

In practice our clients ask most often about two domains — we explicitly place them in the ADM here:

Data architecture with TOGAF

Data architecture (one of the four TOGAF domains) describes the structure of an organisation’s logical and physical data assets and how they are managed across the enterprise. TOGAF places data architecture work in the ADM as follows:

• Phases B & C: develop data views (logical and physical) — from data inventory through master and reference data views to target-state data models, coupled to the business processes (phase B) so that data does not arise in an IT silo but is derived from the business architecture.
• Phases E & F: identify data initiatives (e.g. master data build-out, data platform) as solutions and sequence them in the migration roadmap.
• Governance (phases G/H): data ownership, data quality and change approvals are governed through the same governance framework as any other domain.

IT architecture (technology architecture) with TOGAF

Technology architecture — commonly just called IT architecture — defines the software and hardware capabilities, platforms, networks, operations and security for deploying business, data and application services. The key ADM connection points:

• As-is capture: document landscapes across platforms and networks to make redundancies and dependencies visible and consolidable.
• Target state: derive the technology target architecture from the business and data objectives — not the other way round from the favourite tool.
• Roadmap coupling: tie technology decisions to work packages in phase E (Opportunities & Solutions) so every technology initiative maps to a business objective; verify through the compliance reviews in phases F/G.

Boundary note: TOGAF explains how to develop, govern and evolve data and IT architecture systematically — it does not deliver ready-made target states or a notation. Both emerge in the project, typically modelled in ArchiMate, and are structured by TOGAF®-certified consulting (the Portamus TOGAF portfolio).

TOGAF and enterprise architecture management

TOGAF is the leading method within the broader discipline of Enterprise Architecture Management (EAM) – the ongoing practice of aligning business and IT and steering their evolution. TOGAF supplies the how; EAM is the management practice that keeps the architecture alive and used for decisions. One of the most concrete EAM activities is Application Portfolio Management — the structured TIME assessment of the application estate to surface redundancies, end-of-life risk, and consolidation potential. In the age of agentic AI, that steering capability matters more, not less: autonomous systems need clear principles, permitted actions and human-in-the-loop points – all of which TOGAF’s Preliminary/Phase A principles and Requirements Management are built to provide.

Conclusion

TOGAF is the proven, adaptable method for enterprise architecture: a structured, iterative way – via the ADM – to move an organisation from its current to its target architecture, with governance built in. It is not a notation and not a rigid rulebook; its value depends on tailoring it wisely and applying it with experience. Our consistent experience from Portamus client projects: combine TOGAF as method with ArchiMate as modelling language, right-size it to your organisation, and you get an architecture that is genuinely steerable – not merely documented.

Want to introduce or tailor TOGAF in your organisation? We guide you from method selection to a working, governed architecture practice — as a TOGAF®-certified partner, from ADM application through governance. → Discover Portamus Enterprise Architecture consulting · TOGAF® certification & Portamus TOGAF portfolio