Architecture
levels and other things to know about the TOGAF standard
Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last
updated 01/11/2017 08:56
ArchiMate®, The Open
Group®, TOGAF®, UNIX®, are registered trademarks, and Boundaryless Information Flow™ 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.
Some equate the framework with Enterprise Architecture (EA).
Do your customers presume that EA is “doing TOGAF”?
This paper may help you educate them in how the framework decoupled itself from EA.
“Great paper on
TOGAF vs EA. Have shared it with my colleagues” Linkedin
member
Contents
Five
levels of architecture (yes five)
Service-oriented
architecture development principles
System
theory concepts in architecture frameworks
The
history of the TOGAF standard
The
seven parts of the framework
References
and further reading
People use the term EA with a variety of meanings.
So to begin with, here are three brief observations on what might be called mainstream EA.
First, EA is not executive level business planning; rather, EA is business system planning.
EA supports strategic business planning, and sometimes, the two go hand in hand, but not always.
Second, an EA team is not solely responsible for transforming or changing business systems.
It must work in coordination with business planning, project management and IT services/operations management.
Third, EA is more than managing a portfolio of discrete or silo systems or projects.
Historically, EA started as a reaction to the costs, risks and issues created by silo systems.
“Enterprise-level architecture is required to constrain the [system] design and development activity.” Zachman 1982
It is about cross-organisational optimisation, integration and standardisation of business systems (Ross, Weill and Robertson, 2006 reference).
Today, the TOGAF standard is a management framework for what it calls "architecture projects".
Each is an architecture-intensive project to design, plan and govern changes to one or more business systems.
The framework can be used in a way that supports and enables the work of enterprise architects.
However, using it as a framework for a discrete solution delivery project does not make you an enterprise architect.
While the framework is not EA, it is certainly relevant to EA.
Both are concerned to address the benefits, costs and risks of changing business systems and IT-related work.
The framework urges you to relate all business system change plans back to executive-level business goals, drivers and strategy.
Running a class for an EA team of five, it turned out three of them had previously attended a different, soporific, course in the TOGAF standard.
We began by discussing and agreeing: it provides a management framework for “architecture projects” at whatever level you choose to do them.
Version 9.1 of the standard divides
architecture into five levels, as shown in the table below.
Comparing the levels discussed in different
chapters, the distinctions drawn between them are roughly but not exactly
consistent.
|
|
Architect Roles as defined in chapter
52 --------------- Architecture Landscape as defined
in chapters 3, 20 and 41 |
A longer interpretation of the roles at different levels |
|
Enterprise Architecture |
Enterprise architect: works at a landscape and technical reference
model level. Focuses on enterprise-level business functions required. Often leads a group of Segment Architects/Solution Architects related
to a given program. --------------- A summary formal description of the enterprise. An executive-level, long-term view. |
Enterprise architects work at the cross-organisational and strategic
level: are concerned to optimise,
standardise and integrate business systems, maintain a summary description
of the enterprise and its system, maintain standards,
principles, reference models and patterns, develop roadmaps for change
at a strategic, executive-level, govern
architects working at lower levels. |
|
Segment Architecture |
Segment architect: works on specific business problems or for a
specific organization. Focuses on enterprise-level business solutions in a given domain. --------------- A detailed, formal description of an area within an enterprise. Architecture roadmaps at a program or portfolio level. |
Segment architects work for a division or domain of an organization: act as enterprise architects
for the portfolio of solutions/systems in their business area, maintain a description of
their division or domain and its systems, develop roadmaps for change
at a portfolio or program or level, govern
architects working at lower levels. |
|
Solution Architecture |
Solution architect: works on a system or subsystem. Focuses on system technology solutions --------------- A description of a discrete and focused business operation or
activity, supported by IS/IT. Typically applies to a single project or project release. |
Solution architects shape a solution and join up the technical
specialists who work on it: address the problems and
requirements of a particular business operation, work to deliver a new or
changed system using particular information technologies, guide projects managers as to
the time, cost and risks of project-level work, maintain descriptions at the
solution outline or high-level design level, develop roadmaps for change
at a project or release level, govern
project work (designers, technical specialists, developers, builders and configurers). |
|
Capability Architecture |
A highly detailed description of the architectural approach. to realize a particular solution or solution
aspect. Architecture roadmaps realizing capability increments. How the enterprise can support a particular unit of capability. Allow for individual work packages and projects to be grouped. |
Designers and technical specialists complete detailed designs. Guide those who develop, build, configure and deploy systems. |
|
Capability Increment |
A discrete portion of a capability architecture that delivers specific
value. |
Work package? |
On architecture at
the SA level
The term solution architecture has been used for several decades.
It has long been embedded in the Skills Framework for the Information Age, and it is the level at which the ADM is often applied.
For discussion differentiating EA from SA, read Enterprise and Solution Architecture.
On architecture
at the EA level
The purpose of mainstream EA has always been to optimise and improve core business processes.
“An EA establishes the Agency-wide roadmap to achieve an Agency’s mission through optimal performance of its core business processes within an efficient IT environment.” (FEAF, 1999 reference).
“Companies excel because they've [decided] which processes they must execute well, and have implemented the IT systems to digitise those processes." (Ross, Weill and Robertson, 2006 reference).
“The purpose of EA is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment.” (TOGAF 9.1, 2009 reference)
EA emerged in the 1980s out of business system planning.
A solution architect’s vision usually has a relatively short time frame and narrow scope.
Enterprise architects take the broadest possible view, look to standardise, integrate and coordinate business systems across an enterprise.
They respond to the outputs of business planning, align system changes with them, and may influence them.
|
Business
Planning |
Business mission,
vision, drivers, strategies, goals and top-level business plans. Mergers,
acquisitions, divestments, internal organisation restructurings and rationalisations. |
|
|
Enterprise
Architecture (Business Systems Planning) |
Business Architecture |
Business
functions/capabilities, roles, processes/value streams and their
interrelationships. The services they
provide to each other and to entities in the business environment. |
|
Information System Architecture |
Applications and
their interrelationships The services
applications provide to each other and to business activities. Data stores and
data flows, the data structures they contain and the qualities of that data. |
|
|
Technology Architecture |
Platform
technologies and their interrelationships The services
technologies provide to each other and to business applications. |
|
EA is challenging politically as well as technically.
The idea is to take a cross-organisational and strategic
perspective of the architecture domains in the table above.
To do this, architects need not only appropriate knowledge, skills and resources, but also cross-organisational authority.
The two primary architecture deliverables (from phases B, C and D of TOGAF) are Architecture Building Blocks and Architecture Requirements Specification.
This division, between structural elements and required behaviors, appears in most system modelling standards, including UML, TOGAF and ArchiMate.
|
The UML standard - two premises of system
modelling |
|
The TOGAF standard – two primary
architecture deliverable types |
|
“all behaviour [is]
caused by actions executed by so-called active
objects.” |
= |
Architecture Building
Blocks (logical capabilities/functions/components) realised by Solution Building Blocks |
|
“behavioral semantics
only deal with event-driven, or
discrete, behaviors.” |
= |
Architecture Requirements Specification (inc.
contracts for discrete services
provided by building blocks). |
The same division can be seen in three principles that are explicit or implicit in many chapters of TOGAF.
· Principle 1: An enterprise architecture is composed of interoperating building blocks.
· Principle 2: An enterprise architecture is an abstract/logical description of building blocks and their interactions.
· Principle 3: The generic meta model is: required behaviors <are assigned to> logical building blocks <are realised by> physical building blocks.
The appearance and reappearance of these principles is what gives TOGAF coherence and consistency.
The "primacy of behaviour" principle says that the internal structure of a building block is secondary to its behaviors.
The building blocks are required to perform behaviors that deliver services or outputs of value to other building blocks and/or external entities.
Solution building blocks (actors/components of all kinds) are hired, bought or built to realise architecture building blocks, and so perform the required behaviors.
For a more detailed discussion of the three principles read Three principles that underpin TOGAF.
The TOGAF standard has always been thoroughly service-oriented.
All architecture domains and building blocks within them are defined by the services they offer.
The table below shows the terms used when abstracting services from building blocks.
|
Generic meta model |
Generic
entities |
Business |
Applications |
Technology |
|
Required
behaviors |
Services |
Business Services |
IS/Application Services |
Platform/Technology Services |
|
Structures |
Building
Blocks |
Functions & Roles |
Application Components |
Technology Components |
A system is bounded - distinct from the
world outside the system.
The boundary across which things flow is often logical rather than physical.
Nothing in the universe is a bounded system
until it is named and described as such.
When you look for them, describable systems can be found everywhere,
interrelated, nested and overlapping.
Every designed system has some structures that perform some behaviors to meet some aims.
A system can be described in terms of aims (why), behaviors (how and when), structures (who and what) and the locations where structures are found.
This table generalises how these concepts appear in frameworks like the TOGAF and NAF standards, and modelling languages like the ArchiMate and UML standards.
|
Business architecture
concepts |
General definitions |
|
Aims |
motivations for behavior |
|
Goal or Objective |
a target to be achieved, a motivation or reason to perform behaviors. |
|
Behaviors |
performances over time that change the state of a system or its
environment |
|
Service |
a discrete requestable behavior
that produces a desired result (output or effect), and is definable in a
contract. |
|
Process |
a sequence of activities that leads to the provision of a service or
other result. |
|
Active structures |
entities that perform behaviors |
|
Function |
a logical subsystem, describable externally by services provided and
internally by activities assignable to one or more organisation units. |
|
Role |
a logical subsystem, describable externally by services provided and
internally by activities assignable to one or more actors. |
|
Organisation unit |
a real world business division given the responsibility of fulfilling
one or more logical functions. |
|
Actor |
a real world person or system given the responsibility of fulfilling
one or more logical roles. |
|
Passive structures |
entities that are acted on |
|
Physical entity |
a concrete entity type that a business creates and/or uses in the
course of performing behaviors. |
|
Data entity |
a record type that describes the attributes of a physical or logical
entity or event, which is created and used in the course of performing behaviors. |
|
Location |
a place in space where a structure can be found. |
Aside: in UML, roles are called actors; in
the ArchiMate standard, both people and organisation units are called actors; the
table above separates people from organisations and roles.
And note that whereas a human actor is a unique biological individual, a software actor is a replicable logical individual.
This table classifies some core concepts in the TOGAF standard.
|
System theory |
Come core concepts in the TOGAF
standard |
|
Levels
of abstraction |
Requirements, Logical components or ABBs, Physical components or SBBs. |
|
Aims |
Goal, Objective, Requirement |
|
Behaviors |
Service, Business service, Information system
service, Platform technology service, Process, Scenario |
|
Active
structures |
Function, Organisation Unit, Role, Actor,
Application component, Technology component |
|
Passive
structures |
Data Component, Data Entity, Location |
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.
The Open Group’s vision is: “to achieve Boundaryless Information Flow™ through global interoperability in a secure, reliable and timely manner.”
Their mission is: “enabling access to integrated information within and between enterprises, based on open standards and global interoperability.”
They look to realise their vision and mission through the development of IT standards that make information systems portable and interoperable.
Version 1 to 7 – for IT architecture
The Clinger–Cohen Act, formerly the Information Technology Management Reform Act (ITMRA), is a 1996 United States federal law.
It was designed to improve the way the federal government acquires, uses and disposes information technology (IT).
It demanded that federal government CIOs
maintain a “sound and integrated IT architecture repository”.
TOG members developed versions 1 to 7 of the
framework as an approach based on using the Technical
Reference Model (TRM) discussed below
So, it was then an enterprise technology architecture framework - sometimes called EITA, rather than EA.
Version 8 – the Enterprise Edition
Version 8 shifted its emphasis from technology architecture to business architecture.
This "Enterprise Edition" borrowed a great deal from the US government’s Federal EA Framework (1999).
FEAF declared its aims as:
· “common data and business processes”
· “information sharing” and
· “new and improved processes”.
Version 8 extended the service-oriented architecture development
approach already used in version 1 to 7.
"TOGAF
Version 8… uses the same underlying method for developing IT architectures that
was evolved [in] TOGAF up to and including Version 7.
That method was to define a system or
component, an architecture domain or layer, logically, by the services it provides.
Version 8
applies that… method to the other domains of an overall Enterprise Architecture
- the Business Architecture, Data Architecture, and Application Architecture,
as well” http://www.opengroup.org/architecture/togaf7/index7.htm
Version
9 – a more flexible process
Version 9 shifted focus downwards from the EA level towards solution architecture.
Versions 1 to 7 had been enterprise-wide, but infrastructure technology-oriented.
Versions 8 and 9 had become more business-oriented, but also more project-oriented, with side bar references to EA.
The focus is now less on EA level work –
portfolios, reference models, business function/capability definition etc.
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 links to further observations.
This section has been trimmed back; it now gives links to another paper for those wanting more insights.
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 |
For more insights, read Observations on the 7 parts of the TOGAF standard.
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. |
For more insights, read Observations on the 7 parts of the TOGAF standard.
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 TOGAF does not
teach architects how to do architecting!
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
· Fractal ADM levels
· Service-oriented ADM
· Security-oriented ADM
For more insights, read Observations on the 7 parts of
the TOGAF standard.
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.
As I understand it, these three principles underpin TOGAF's content framework and its meta model.
1. An enterprise is composed of interoperating building blocks (components, functions, organisation units, roles, actors, nodes).
2. An enterprise architecture is an abstract (conceptual, logical) description of building blocks, their interactions and the services they provide.
3. The generic meta model is: required behaviors <are assigned to> logical building blocks <are realised by> physical building blocks.
These principles, reasonably clear in TOGAF 7 and 8, were obscured in TOGAF 9.
However, the ADM does explain the principles in the following sections.
· Application(s) architecture: 11.4.1.2
· Technology architecture: 12.4.1.2 and 12.4.1.6 (These few sentences are the last vestige of TOGAF 7)
· Business architecture: 8.4.1.2 (TOGAF differentiates between the functions of a business and the services of a business.)
(Unfortunately, the rest of 8.4.1.2 obscures rather than clarifies.)
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.
However, not all of
the relationships (left and right, up and down) 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 |
For more insights, read Observations on the 7 parts of the TOGAF standard.
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 |
|
|
||||
For more insights, read Observations on the 7 parts of the TOGAF standard.
“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.
· The Information Infrastructure Reference Model (III-RM) is for cross-organisational integration of application components
· The Technical Reference Model (TRM)is for cross-organisational standardisation of technology components
For more insights, read Observations on the 7 parts of the TOGAF standard.
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.
For more insights, read Observations on the 7 parts of the TOGAF standard.
It is difficult to get to grips with the framework just by reading it.
Or by attending a course presented by a tutor who qualified by passing the certification exams.
It helps to understand the context for the framework and its evolution to date:
· US legislation that directed CIOs to maintain an IT architecture repository.
· US federal government guidance on what EA means.
· The broad methodology history that the framework draws from.
· Various systems analysis and design methods and architecture frameworks.
· The Open Group, its mission, vision and service-oriented specification principles.
· The processes by which the framework’s content is developed.
Nobody is employed to write the framework; you might say it is crowd-sourced.
Any architecture forum member can request a change or draft a contribution.
From that point to publication in the framework is a long and democratic process.
There is no director or editor you can press to address your special concern.
The framework’s scope is determined by what forum members choose to write about.
If you want to contribute, then join the forum.
The framework tends to lag behind the times; it does not anticipate trends or publish speculative practices.
It contains only what has been approved by enough forum members
As things stand, the refresh cycle takes several years (remember training courses and examinations have to be updated).
The framework is free to read!
The astonishing thing is not that the framework is flawed; it is that it is reasonably coherent and consistent.
Enterprise
and Solution Architecture: How do they differ?
TOGAF mapped to NATO Architecture
Framework
A fuller
version of text distilled in the table at the top of the paper.
|
TOGAF 9.1 Section |
3 |
20.2 |
20.2 |
20.2 |
41.2 |
|
|
|
Provides an organizing framework for |
Allows for |
The development of effective |
|
|
Enterprise or Strategic Architecture |
A summary formal description of the enterprise An executive-level, long-term view |
operational and change activity |
direction setting an executive level. |
|
A long-term summary view of the entire
enterprise. |
|
Segment Architecture |
A detailed, formal description of an area within
an enterprise used at the program or portfolio level |
operational and change activity |
direction setting |
architecture roadmaps at a program or portfolio level. |
More detailed operating model for an area within
an enterprise. |
|
Solution architecture |
A description of a discrete and focused business
operation or activity How IS/IT supports that operation. Typically applies to a single project or project
release. |
|
|
|
|
|
Capability Architecture |
A highly detailed description of the
architectural approach to realize a particular solution or solution aspect. |
change activity |
|
architecture roadmaps realizing capability increments. |
In a more detailed fashion how the enterprise can
support a particular unit of capability. Provide an overview of current capability, target
capability, and capability increments Allow for individual work packages and projects
to be grouped within managed portfolios and programs. |
|
Capability Increment |
A discrete portion of a capability architecture
that delivers specific value. |
|
|
|
|
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.