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
Contents
The
history of the TOGAF standard
Part
2: The Architecture Development Method (ADM)
Part
3: ADM guidelines and techniques
Part
4: Content framework (documented products)
Part
5: The enterprise continuum and repository
Part
6: The two reference models
Part
7: Architecture capability (especially roles in governance)
References
and further reading
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.
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 |
Coordinated |
Unified |
|
Low integration |
Diversified |
Replicated |
|
|
Low standardisation |
High standardisation |
Observations
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).
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 |
|
Preliminary |
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. |
Observations
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.
Below are some observations
on the chapters that outline 10 techniques used during the ADM and 4 guidelines
for adapting it.
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.
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.)
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.
|
|
Deliverable |
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 |
|
Location |
|
Business service |
Function |
Organisation unit |
||
|
Process |
Role |
Actor |
||
|
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> |
Applications |
Application/function matrix |
|
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 |
||||
|
Requirements and context |
|
Requirements repository |
||||
|
Architecture continuum |
Foundation architecture |
Common systems architecture |
Industry architecture |
Organisation architecture |
Architecture BBs |
Architecture repository |
|
Solution continuum |
Foundation solutions |
Common systems solutions |
Industry solutions |
Organisation solutions |
Solution BBs |
Solutions repository |
|
Deployed
solutions |
|
|
||||
Observations
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.
“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.
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 |
|
Preliminary |
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.
Observations
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.
Enterprise
and Solution Architecture: How do they differ?
TOGAF mapped to NATO Architecture
Framework
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.