TOGAF’s seven parts

This page is published under the terms of the licence summarized in the footnote.

All free-to-read materials on are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to in whichever social media you use.

TOGAF® ArchiMate® are registered trademarks of The Open Group.



TOGAF is published on the Open Group web site and in book form. (The associated study guide differs in places.)

It is freely available for viewing online without a license. It may be downloaded and stored under license, as explained on the web site.

It may be used freely by any organization wishing to develop an architecture for use within that organization.


TOGAF contents wrt to Architecture Definition. 1

Part 1. Introduction. 3

Part 2. The Architecture Development Method (ADM) 4

Part 3. ADM guidelines and techniques. 5

Part 4. The Content Framework. 6

Part 5. The Enterprise Continuum, Repository and Tools. 7

Part 6. Reference Models. 9

Part 7. Architecture Capability. 10



TOGAF contents wrt to Architecture Definition

TOGAF 9 is divided into seven parts and 52 chapters.



Relevance to Architecture Definition


1.      Introduction

introduces methods and tools for accepting, producing, using,

and maintaining enterprise Architecture Definitions.

Process: steps and guidance

2.      The Architecture Development Method (ADM)

describes a step-by-step approach to developing an Architecture Definition and using it.

3.      ADM guidelines and techniques

contains a collection of guidelines and techniques for developing an Architecture Definition

Products: documents and models

4.      The Content Framework

describes the elements of an Architecture Definition - architectural entities and artifacts.

5.      The Enterprise Continuum and Tools

discusses taxonomies (Architecture Continuum) and tools (Architecture Repository)

to categorize and store Architecture Definition elements

6.      Reference Models

provides two reference models for structuring parts of an Architecture Definition.

People: organisation and governance

7.      Architecture Capability Framework

offers guidance for the “Architecture Capability”, that is,

the organisation that develops and maintains Architecture Definitions


This paper introduces TOGAF with high level overviews and links to papers that contain more detail.


“Enterprise architects approach their job through the consistent use of recognized design methods such as the TOGAF Architecture Development Method.”

Part 2 ADM phases

The Architecture (not System) Development Method is based on the phases below.

·         Preliminary: establishes the EA team and their authority

·         Phase A: produces an Architecture Vision - a sketchy Architecture Definition.

·         Requirements management: ensures the Architecture Definition addresses documented requirements, and manage changes to requirements.

·         Phases B, C, D: develop a logical Architecture Definition.

·         Phases E, F: plan projects to implement the Architecture Definition in systems, and so establish the “Architecture Lifecycle”.

·         Phase G: While a PMO runs implementation projects, architects govern to ensure implemented systems are Architecture Definition-compliant.

·         Phase H: While an ITSM organisation manages system changes, architects govern to ensure changed systems remain Architecture Definition-compliant.

Part 3 Guidance and techniques

This includes advice on shaping and steering Architecture Definitions.

Chapter 19: Applying Iteration to the ADM: encourages iteration in completing an Architecture Definition from phase B to F.

Chapter 20: Applying the ADM at Different Enterprise Levels: structures enterprise Architecture Definitions into levels of abstraction.

Chapter 23: Architecture Principles: these are used to ensure conformance of the Architecture Definition to principles.

Chapter 24: Stakeholder Management: this is used to ensure the Architecture Definition meets stakeholder concerns.

Part 4 Content Framework

This is about documenting the elements of an Architecture Definition, and other deliverables.

Chapter 34: The Content meta model: a structure for Architecture Definition building blocks.

Chapter 35: Architectural Artifacts: 90% of the artifacts are used in Architecture Definitions.

Chapter 36: Architecture Deliverables: documents using during the ADM.

Chapter 37: Architecture Building Blocks: descriptions of elements used in architectural artifacts.

Part 5 Enterprise Continuum and Tools

This is about how to divide, classify and store elements of an Architecture Definitions.

Chapter 39: The Architecture Continuum classifies the descriptive building blocks and artefacts of Architecture Definitions.

Chapter 41: The Architecture Landscape contains the descriptive building blocks and artefacts used in Architecture Definitions.

Part 6: Reference Models

This contains two structures for organising parts of an Architecture Definition.

Chapter 44: The TRM is catalogue of abstract platform service descriptions.

Chapter 45: The III-RM is an abstract application integration design pattern.

Part 1. Introduction

This contains four chapters.


Part I: Introduction




Core Concepts




Release Notes


TOGAF is a framework for conducting EA, yet it seems few with a TOGAF certificate know what TOGAF means by that.

Many training course delegates are solution rather than enterprise architects.

Many tutors teach TOGAF as though it were a solution architecture method.


In this context:

An enterprise is an organisation sharing goals and a budget, or that part of it that enterprise architects are sponsored to address.

An architecture describes the structure and behaviour of a system. EA regards the enterprise as a system, or system of systems.


TOGAF is supposed to help enterprise architects treat the enterprise as a system, and manage changes to that system.

A primary output is a description of the enterprise’s architecture that is vendor-neutral and “considerably abstracted from solution architecture”.

The enterprise architecture describes the structure and behaviour of the enterprise’s operational system at an abstract level.


TOGAF says: “The purpose of EA is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment.”

In other words, EA strives to tidy up the mess of systems that is familiar to many working in substantial enterprises.

To this end, TOGAF borrows the operating model concept from the famous “EA as Strategy” book.

Business process - operating model











TOGAF says that conducting EA means

·         “managing the spectrum of change required to transform an enterprise towards a target operating model”

·         [defined by] the necessary level of business process integration and standardization.”


The “spectrum of change” covers four architecture domains: business, IS (data + applications) and IT infrastructure.

These domains can be represented as hierarchical layers in which the components/roles in a lower layer provide services to the components/roles in the layer above. 


Architecture Definition Building Blocks

Phase B: Business Architecture

Business Services

Business Functions, Roles, Actors

Phase C: Information Systems Architecture

Information System Services

Application Components, Data Components, Data Entities

Phase D: Technology Architecture

Platform Services

Technology Components


The definitions chapter is not as well written or helpful as you’d like.

The release notes are probably of little interest to most readers.

Part 2. The Architecture Development Method (ADM)

The core of TOGAF is the ADM: a change management framework for “transforming the enterprise from a baseline architecture to a target architecture.”

Primary products include architecture definition documents and an enterprise-wide architecture repository.

But I’m going to surprise you here.

The ADM’s strength does not lie in architecture definition - it tells you surprisingly little about that - it is rather a management framework for architecture work.

The ADM promotes the idea of architect-led planning, rather than manager-led architecture.

People use it to record a “baseline architecture”, develop a "target architecture" to meet requirements for change, then plan and govern the transformation of systems from the baseline to the target.


The ADM is a ten-phase cyclical process, a generic method that can be adapted for any kind of transformation or change programme that involves information systems.

There is a tenth continuous phase, not listed below, covering management of the requirements.

The table below illuminates the ADM phases with process names used in Avancier Methods.


TOGAF iteration

Architecture Development Method (ADM) phase

Mapped to Avancier Methods


Preliminary Phase


Phase A: Architecture Vision

Establish capability

Establish the context

Scope the endeavour

Get vision approved


Phase B: Business Architecture


Phase C: Information Systems Architecture

Data + Applications Architecture


Phase D: Technology Architecture

Understand the baseline

Review results of initiation

Clarify NFRs

Design the target


Phase E Opportunities and Solutions


Phase F: Migration Planning

Select suppliers

Plot migration path

Review business case

Plan delivery


Phase G: Implementation Governance


Phase H: Architecture Change Management

Hand over to delivery

Govern delivery

Monitor portfolios

Respond to operational change


Click here for more on the ADM.

Part 3. ADM guidelines and techniques

This part contains 4 guidelines for adapting the ADM, and 10 techniques for use during the ADM, some at several points.



Part III: ADM Guidelines and Techniques




Applying Iteration to the ADM


Applying the ADM at Different Enterprise Levels


Security Architecture and the ADM


Using TOGAF to Define & Govern SOAs


Architecture Principles


Stakeholder Management


Architecture Patterns


Business Scenarios


Gap Analysis


Migration Planning Techniques


Interoperability Requirements


Business Transformation Readiness Assessment


Risk Management


Capability-Based Planning


Click here for more on the ADM guidelines and techniques.

Part 4. The Content Framework

Part 4 Content Framework

This is about how to document Architecture Definitions.

Chapter 34: Content meta model is a structure for abstract Architecture Definition.

Chapter 35: Architectural artifacts are mostly used in Architecture Definitions.

Chapter 36: Architecture deliverables are documents using during the ADM.

Chapter 37: Architecture Building Blocks are descriptions of the elements used in architectural artifacts.

This part contains five chapters.


Part IV: Architecture Content Framework




Content Metamodel


Architectural Artifacts


Architecture Deliverables


Building Blocks


TOGAF encourages architects to document architectural assets and maintain this documentation.

The architecture content framework defines content (products or documentation) that architects may produce.

It does not mandate any products, but does define potentially useful:

·         Deliverables: contents lists for word processor documents, which often contain

·         Artefacts: catalogues, tables and diagrams, which describe and relate

·         Building blocks: discrete architectural entities like business role, application and technology.


One building block may appear in several artefacts. One artefact may appear in several architecture descriptions.


Meta model for an architecture repository

A building block is an architectural entity that appears in architecture description.

TOGAF is underpinned by two big ideas:

  • Services (the required behaviour of a system) are provided by components (the designed structure of a system).
  • Logical components are defined before physical (implementation-specific) components.


These two ideas can be used to classify the architectural entities in the TOGAF meta model.

Direction and planning

Principle, Gap, Constraint, Work Package, Assumption, Requirement, Capability

Avancier’s classification

Requirements and behaviour

Logical structure

Physical structure


Driver, Goal, Objective



Service (Service Quality, Measure, Contract)


Organization Unit

Process (Event, Control, Product)




Information System Service

Logical Application Component

Physical Application Component



Data Entity

Logical Data Component

Physical Data Component


Platform Service

Logical Technology Component

Physical Technology Component


Note that TOGAF authors use the term building block in two ways:

·         Loosely: any architectural entity mentioned above, any potentially reusable element of architecture description.

·         Tightly: an encapsulated component; defined by its interface (the functions or services it offers); replaceable by any other building block with the same interface; including business functions, applications and technologies.


Click here for more on the content framework and TOGAF meta models

Part 5. The Enterprise Continuum, Repository and Tools

Architects are expected to store documentation in a repository - using the enterprise’s knowledge management systems, tools and file stores.

Architects are expected to structure and index the repository for ease of access - using structuring and indexing devices such as the Enterprise Continuum.


This part contains five chapters.


Part V: Enterprise Continuum & Tools




Enterprise Continuum


Architecture Partitioning


Architecture Repository


Tools for Architecture Development


The Enterprise Repository is divided into three repositories. TOGAF is centred on the architecture repository.

Enterprise repository

ADM Phase

Enterprise Continuum level

Requirements repository


Context and requirements

Architecture repository

B, C and D

Architecture Continuum

Solutions repository

E, F and G

Solutions Continuum


The architecture repository is divided into six sections. TOGAF is centred on populating the architecture landscape.

Architecture repository




Architecture meta model

Architecture method: tailored version of TOGAF’s ADM

Content meta model: the structure in which architecture entities are related

Architecture documentation

Architecture landscape

Descriptive artefacts

Reference models

Common structures and patterns


Open standards, local standards etc.

Organisation and work

Architecture capability

The architecture team, roles, skills, training etc.

Governance log

Record of compliance assessments due and made


The Enterprise Repository contains many architecture deliverables, artefacts and building blocks. How to find an artefact or building block you are looking for?

There are many ways to classify artefacts and building blocks. Two-dimensional classification schemes like the ones below suggest some indexes for filing elements of documentation.


Indexes to TOGAF’s Enterprise Continuum


Indexes to the Zachman Framework


Change Planning Framework



















Level of detail


Year 1

Year 2




































































Work package










The Enterprise Continuum is a device for classifying artefacts found in the Enterprise Repository.

Think of it as a bookcase with four shelves.

The second shelf – the architecture continuum - contains logical specifications – services, processes and data entities.

The second and third shelves are divided into four pigeon holes representing a spectrum from generic or universal to specific or unique.

Enterprise Continuum


Common System



Context and requirements





Architecture Continuum

e.g. JMS

Unix Spec.

e.g. Required

groupware features

e.g. Domain-specific

data and process models

e.g. Unique

data models and use cases

Solutions Continuum

Web Logic, JBoss

HP-UX, AIX, Solaris, OS X

Groupware product

Domain-specific package

Bespoke applications

Deployed solutions






The Enterprise Continuum encourages you to identify and find artefacts that are reusable - because they are generic (to the left) and/or logical (to the top).


Click here for more on the Enterprise Continuum and Architecture Repository

Part 6. Reference Models

A reference model is a generalized structure (of components, data entities, processes or services) that can be used as starter or template for more specific models.

TOGAF mentions various industry reference models. TOGAF itself offers two (more generic) reference models in two chapters.



Part VI: TOGAF Reference Models


Place in ADM


Foundation Architecture: Technical Reference Model

A hierarchical classification of platform services.

D: Technology architecture


Integrated Information Infrastructure Reference Model

An SOA-style design pattern for applications architecture.

C: Applications architecture


Both reference models are based on the idea that components can be encapsulated behind the services they deliver, and they can be slotted into the Enterprise Continuum as below


Enterprise Continuum


Common System



Context and requirements





Architecture Continuum



Domain-specific RM


Solutions Continuum





Deployed solutions






Click here for more on these two Reference Models

Part 7. Architecture Capability

This part includes 8 chapters that address the organisation and processes of the enterprise architecture team.



Part VII: Architecture Capability Framework




Establishing an Architecture Capability


Architecture Board


Architecture Compliance


Architecture Contracts


Architecture Governance


Architecture Maturity Models


Architecture Skills Framework



Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited:” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see