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® 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.
Contents
TOGAF contents
wrt to Architecture Definition
Part
2. The Architecture Development Method (ADM)
Part
3. ADM guidelines and techniques
Part
5. The Enterprise Continuum, Repository and Tools
Part
7. Architecture Capability
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.”
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.
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.
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.
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.
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.
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.
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.
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 |
|
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.
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:
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
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: |
|
38 |
Introduction |
|
39 |
|
|
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
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
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