Observations on the 7 parts of the TOGAF standard

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 25/10/2017 18:47

ArchiMate®, The Open Group®, TOGAF®, UNIX®, are registered trademarks, and Boundaryless Information Flow™ and IT4IT™,  are trademarks of The Open Group.


This is one of several popular papers on the TOGAF standard that are posted on the home page at avancier.website.

This paper briefly introduces the seven parts of the standard, and adds observations.

This paper was formerly included in this preceding paper on TOGAF basic principles (architecture levels, service-orientation etc).

“Great paper on TOGAF vs EA. Have shared it with my colleagues” Linkedin member


The history of the TOGAF standard. 1

Part 1: Introduction. 1

Part 2: The Architecture Development Method (ADM) 2

Part 3: ADM guidelines and techniques. 3

Part 4: Content framework (documented products) 4

Part 5: The enterprise continuum and repository. 5

Part 6: The two reference models. 6

Part 7: Architecture capability (especially roles in governance) 7

References and further reading. 7


The history of the TOGAF standard

EA had been discussed for about 20 years before the TOGAF standard was published.

Yet to begin with, the framework owed little or nothing to that EA history.

And version 9 decoupled its processes and products from being exclusively about EA.

Read this preceding paper for an explanation of that.


TOGAF is centred on a process, the ADM, which is a management framework for "architecture projects" at any level you choose.

Potential products are described in a content framework and meta model - based on a service-oriented approach to system specification.

Many of the products fit solution architecture better than enterprise architecture.

Read Enterprise and Solution Architecture for discussion of the difference.


The latest version provides a management framework for architecting at high and low levels, but does not teach architecting.

The seven parts of the current standard are introduced below, with observations.

My qualifications to make observations include having taught the framework since version 8, and taught architects before that.

Part 1: Introduction

This first part introduces the context for architecture work, and defines core concepts.

It also promotes the “business operating model” principle (from “EA as Strategy”, 2006) of standardising and integrating processes across the enterprise.

 “Operating model” for core business processes

High integration



Low integration




Low standardisation

High standardisation



The standard presents a general purpose architecture framework – which can be and often is decoupled from EA

It is probably more often used for solution architecture work than for EA.

It does not teach you how to do architecture.

It is a menu of things Architecture Forum members have done on different projects.

It assumes you know how to do these things (though some tutors add value by explaining some of them).

Part 2: The Architecture Development Method (ADM)

The ADM is the core of the framework; it is a process for architecture-intensive work to design, plan and govern business systems.

It presents a menu of phases and activities in a rational sequence – outlined below.

You are expected to tailor the ADM process and meld it into your PMO processes.


ADM phase

Read as an architecture project management framework


Establish the capability to follow the ADM process from A to H (when a request for work arrives).

Requirements management

Capture and manage requirements (continuous)

A: Architecture vision

Conduct feasibility study, get stakeholder approval for work to be done.

B,C,D: Business, IS and Technology architectures

Logical design of business processes and roles, and supporting data, applications and infrastructure.

E: Opportunities and solutions

Identify and select between suppliers and technologies, and plan transition states

F: Migration planning

Plan projects to develop and deploy new/changed systems.

G: Implementation governance

Govern development and deployment projects.

H: Architecture change management

Govern system changes after deployment.



Architects must tailor the ADM to the needs of those who request architecture work, and the wider organisation.

You don’t set out to eat everything on the menu in one cycle.

You select items that will help you address a particular sponsor's particular problems and requirements.


A cycle of ADM starts with a "request for architecture work" (say, to improve our care-in-the-home business operation).

If stakeholders don’t approve the initial “architecture vision” at the end of phase A, then it is not taken forward.

If they do approve it, then the next step is to study the human activity system in more detail.

And after that, how IT can best be used to support and enable that by regularising behaviors that create and use information.

Part 3: ADM guidelines and techniques

Below are some observations on the chapters that outline 10 techniques used during the ADM and 4 guidelines for adapting it.

Ten techniques used during the ADM

Five of the techniques are management-oriented (stakeholder management, risk management, transformation readiness, gap analysis, migration planning).

Five are more architecture-oriented (principles, capability-based planning, business scenarios, patterns, interoperability).


But remember, the standard is primarily a management framework for architects; it does not teach professional architects how to do architecting.

E.g. it mentions structured analysis in one sentence; in a training course, we spend about 45 minutes explaining that.

E.g. it defines a data dissemination diagram in a few sentences; we usually spend an hour or two on that, and a process for using it.

Four guidelines for adapting the ADM

You are not expected to follow the ADM process in a strictly sequential fashion.

You tailor it, in concert with other methods your organisation uses.

There are four guidelines for modifying the use of and activities in the ADM.


Iterative ADM

The ADM is widely misunderstood as a strictly sequential process.

First, it can be applied any of several levels of decomposition (see above) and in parallel on different requests for architecture work.

Then, readers are encouraged to iterate:

·         the whole ADM cycle (rapidly if need be)

·         between phases of the ADM cycle

·         between baseline and target architecture definition

·         between activities within an ADM phase.


Fractal ADM levels

Look again at the table at the top of this paper.

There are at least three levels of architecture, Enterprise/Strategic, Segment and Capability/Solution Architecture.

And beware this ambiguity.

In business architecture, a capability is "high-level function”, and might correspond to the "segment" level in the architecture landscape

In the architecture landscape a capability is very different; it is a "highly-detailed… solution or solution aspect".


Service-oriented ADM

The framework has always been thoroughly service-oriented, as defined in the section above.

The chapter on SOA adds little of value.


Security-oriented ADM

The framework is not a security framework.

But it does help you position security considerations in the ADM process.

The chapter on security maps security considerations from NIST standards to ADM phases.

(UK architects would more likely map the ISO 27001 standard to ADM phases.)

Part 4: Content framework (documented products)

The framework does not prescribe how you document architectures.

It does contain an extensive menu of products that may be produced by architects during the phases of the ADM.

There is also a meta model indicating how the elements of these products are related.


In the table below…

The yellow-shaded boxes name core architecture entities in the TOGAF meta model.

The grey-shaded boxes name other concepts in the TOGAF content framework.

Most things in the same row connect to each other – left to right.

Most things in the same column connect to each other – up and down.

But not all of these relationships are clear in the standard text, and some are a little more complex.




Architecture requirement specification

Architecture definition document

Architecture roadmap

Enterprise repository

Requirements repository

Architecture repository

Solution repository

Enterprise continuum

Requirements and context

Architecture building blocks

Solution building blocks

Phases and domains


Required behaviors

Logical structures

Physical structures

Phase B

Business architecture


Business goal/objective



Business service


Organisation unit




Phase C

IS architecture

III reference model

IS (app) service

Logical application component

Physical application component



Data Entity

Physical data component

Logical data component

Phase D

Technology architecture

Technical reference model

Platform (technology) service

Logical technology component

Physical technology component


Observations on business architecture

The framework includes more artifacts for documenting a business architecture than any other architecture domain.

It starts with analysis of required business goals, business services and the business scenarios required to deliver them.

The framework’s business architecture (approach and artifacts) is based on “structured analysis”.

It takes 30 to 45 minutes in a training course to explain and illustrate this, but here are a few key elements.


Structured analysis defines at least one logical business function structure, independent of the organisation/management structure.

This function structure relates functions by composition and decomposition in a hierarchical “tree”.

Any function (at any level you choose) can be related in a matrix or diagram artefact to other architectural entities.

The breadth and depth of the analysis varies from situation to situation.

Functions <are related  to>

Other architectural entities

TOGAF standard artefact

Other terms used

Functions <provide>

Services  (the external view of a function)

Business service/function catalogue


Functions <are composed of>

Functions/activities (the internal view of a function)

Functional decomposition

Capability map/hierarchy

Functions <serve>

Functions/external Roles (with information/material flows)

Node connectivity diagram

Dependency network diagram

Functions <trigger>

Functions (in sequential processes)

Process flow diagram

Value stream

Functions <are fulfilled by>

Organisation units (which perform activities)

Organisation/function matrix


Functions <create and use>

Data entities

Data entity/function matrix


Functions <are served by>


Application/function matrix


Part 5: The enterprise continuum and repository

The enterprise repository is a data store that contains architecture definition building blocks and artifacts.

The enterprise continuum is merely a tabular structure for classifying architecture definition building blocks and artifacts.

In effect, it is a two-dimensional index to some of the repository content.


Enterprise Continuum

Buildings blocks

Enterprise Repository


and context








Common systems






Architecture BBs







Common systems






Solution BBs









Implicit here is a rejection of how the Zachman Framework was used in the 1990s.

People wasted time and energy filling up the 6 by 6 Zachman Framework, documenting everything in the enterprise from every perspective and at 5 levels of abstraction.


You never “do TOGAF”, or attempt to fill the architecture repository for its own sake.

You use the framework as checklist for architecture work to be done in response to a sponsor’s request for work.

You populate the repository as a side effect of sponsored work.

It is questionable how many users of the framework do maintain a coherent enterprise repository.

Part 6: The two reference models

“Enterprise-level architecture is required to constrain the [system] design and development activity.” Zachman 1982

A reference model is a general structure or pattern that helps to constrain or steer system design activity.


“EA is concerned with “system implementations, extending in scope and complexity to encompass an entire enterprise.” Zachman.

“EA regards… the enterprise as one system, or a system of systems” TOGAF 9.1

The two reference models help architects to treat an enterprise as one system.


Information Infrastructure Reference Model (III-RM) for cross-organisational integration of application components

In the early 1980s, an EA vision was to consolidate the entire applications portfolio in one application, with one database

As time passed it became harder and harder to maintain that vision.


By the 1990s, a large enterprise might maintain scores or hundreds of substantial business databases.

So, the vision changed to that of cross-organisational application integration.

The Open Group declared their vision to be that of “Boundaryless Information Flow” via application integration


Version 8 introduced the III-RM as a means to enable “Boundaryless Information Flow”.

The III-RM is a design pattern for application integration (though only one of many design patterns that may be used for this purpose).

The idea is to give end users the appearance of one application with one database.


The Technical Reference Model (TRM) for cross-organisational standardisation of technology components

In 1990s, the US “IT Management Reform Act” demanded that federal government CIOs maintain a “sound and integrated IT architecture repository”.

Versions 1 to 7 developed as framework for IT architecture (sometimes called EITA, rather than EA).

The idea was to help IT service managers de-duplicate (or rationalise) their enterprise’s platform technology estate.

The TRM is classification structure used in this rationalisation process.


The idea is to envision the entire platform technology layer as one technology component.

And to encapsulate that layer behind a one logical interface, offering thousands of discrete platform services.

The TRM is a nothing more or less than a high-level definition of that logical interface.

It classifies and groups the platform services provided by platform technologies, and helps people analyse their baseline technology estate


The TRM chapter defines the interface to platform technologies, but not process for rationalising that platform.

The transformation approach is to bundle the platform services into “cohesive clusters” assignable to discrete logical technology components.

Then choose target physical technology components to realise those logical technology components, more efficiently than before.

That approach (defined in version 1 to 7, and Phase D of version 8) has been compressed to brief aside in phase D of the ADM.

Phase D of the ADM now presents instead an approach to developing the technology architecture for a single solution.

Part 7: Architecture capability (especially roles in governance)

This last part is about the roles of architects in an enterprise, especially in governance.

This table highlights core governance activities in the framework.

ADM phase

Core governance activities


Establish the architecture board and governance structure

A: Architecture vision

Produce a contract for B to F: The Statement of Architecture Work.

B to F (The architecture project)

G: Implementation governance

Govern development and deployment projects – to development contract

H: Architecture change management

Govern system changes after deployment – to business users contract


There is governance of architects by an architecture board.

There is governance by architects of system development/implementation and system change.



The architecture board publish generic principles, standards, road maps etc. to which architects are expected to conform.

Architecture Governance

Architecture Practice

Principles, standards etc.

<publish>                        <used by>

Architecture board  <monitor and guide> Architects

Architecture definitions

<create and use>        <realised by>

Architects  <observe and envisage>  Systems


Architects cooperate with management roles performed by others

·         Project managers manage projects to implement systems designed by architects.

·         IT services management (change advisory board) manage work to change live systems.

Architects ensure projects and changes accord with architecture principles, standards and whatever architecture definition has been developed.

References and further reading

Mainstream EA reference list

Enterprise and Solution Architecture: How do they differ?

TOGAF mapped to NATO Architecture Framework

TOGAF core concepts


All free-to-read materials at http://avancier.website 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 avancier.website in whichever social media you use.