TOGAF’s seven parts

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

All free-to-read materials on 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.co.uk in whichever social media you use.

 

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.

Contents

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.

About

Part

Relevance to Architecture Definition

Introduction

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.

Chapter

Part I: Introduction

1

Introduction

2

Core Concepts

3

Definitions

4

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

Standardisation

Coordination

Unification

 

Diversification

Replication

 

 

Integration

 

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. 

TOGAF Phase

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

CAPABILITY

Preliminary Phase

 

Phase A: Architecture Vision

Establish capability

Establish the context

Scope the endeavour

Get vision approved

DEVELOP

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

PLAN

Phase E Opportunities and Solutions

 

Phase F: Migration Planning

Select suppliers

Plot migration path

Review business case

Plan delivery

GOVERN

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.

 

Chapter

Part III: ADM Guidelines and Techniques

18

Introduction

19

Applying Iteration to the ADM

20

Applying the ADM at Different Enterprise Levels

21

Security Architecture and the ADM

22

Using TOGAF to Define & Govern SOAs

23

Architecture Principles

24

Stakeholder Management

25

Architecture Patterns

26

Business Scenarios

27

Gap Analysis

28

Migration Planning Techniques

29

Interoperability Requirements

30

Business Transformation Readiness Assessment

31

Risk Management

32

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.

Chapter

Part IV: Architecture Content Framework

33

Introduction

34

Content Metamodel

35

Architectural Artifacts

36

Architecture Deliverables

37

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

Business

Driver, Goal, Objective

 

Location,

Service (Service Quality, Measure, Contract)

Function

Organization Unit

Process (Event, Control, Product)

Role

Actor

Applications

Information System Service

Logical Application Component

Physical Application Component

Data

 

Data Entity

Logical Data Component

Physical Data Component

Technology

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.

Chapter

Part V: Enterprise Continuum & Tools

38

Introduction

39

Enterprise Continuum

40

Architecture Partitioning

41

Architecture Repository

42

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

A

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

Section

Content

Methodology

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

Standards

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

Generalisation

Idealisation

Universal

Common

Shared

Unique

x

x  

Question

Idealisation

What

How

Where

Who

When

Why

x

Time

Level of detail

Baseline

Year 1

Year 2

Target

Contextual

 

 

 

 

 

Contextual

 

 

 

 

 

 

 

Strategy

 

Conceptual/logical

 

 

 

 

 

Conceptual/logical

 

 

 

 

 

 

 

Programme

 

 

Physical

 

 

 

 

 

Physical

 

 

 

 

 

 

 

Project

 

 

 

 

Real

 

 

 

 

 

Real

 

 

 

 

 

 

 

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

Foundation

Common System

Industry

Organisation

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.

 

Chapter

Part VI: TOGAF Reference Models

Description

Place in ADM

43

Foundation Architecture: Technical Reference Model

A hierarchical classification of platform services.

D: Technology architecture

44

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

Foundation

Common System

Industry

Organisation

Context and requirements

 

 

 

 

Architecture Continuum

 TRM

III-RM

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.

 

Chapter

Part VII: Architecture Capability Framework

45

Introduction

46

Establishing an Architecture Capability

47

Architecture Board

48

Architecture Compliance

49

Architecture Contracts

50

Architecture Governance

51

Architecture Maturity Models

52

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: http://avancier.co.uk” 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  http://creativecommons.org