Making
sense of TOGAF™
One of more than 200 papers at http://avancier.website Copyright Graham
Berrisford. Last updated 30/09/2016 21:35
TOGAF is a multi-authored
product, and not entirely consistent about the nature of enterprise and solution
architecture.
But if you understand
and apply its basic premises to your reading of it, you can make it more coherent
and consistent.
This paper provides resolutions
to several uncertainties and confusions about what TOGAF means.
Contents
1:
Architecture building blocks v. solution building blocks
2:
Enterprise architecture (EA) v. solution architecture
3:
EA-level roadmaps v. “architecture roadmaps”
4: Distinguishing different
abstraction hierarchies
The Open Group’s Architecture Framework, TOGAF, says “enterprise architecture regards the enterprise as a system, or system of systems”.
The Open Group’s vision is “to achieve Boundaryless Information Flow™ through global interoperability” of systems.
General system theory emerged out of sociology and biology.
Organs in a body interoperate by exchanging signals and performing biological processes to produce products and/or maintain the state of the body.
People in a social system interoperate by exchanging messages and performing social processes to produce products and/or maintain the state of the system.
TOGAF's domain is human and computer activity systems - in which the interacting parts are called actors and components.
The broad aim is to enable and support, standardise and integrate, and generally optimise business roles and processes that create and use business data.
TOGAF is not only about computing and digital transformation.
Human activity systems are at the start and end of everything enterprise architects do.
Human and computer activity systems are similar in some ways, different in others.
Enterprise architects cannot control both kinds of system to the same degree.
They strive to govern the specification and deployment of application and technology components.
They are not in control of business strategy, the structure of organisation units or the recruitment and motivation of human actors.
But they do model a business at a more abstract level - in terms of logical business functions/capabilities and roles.
The Open Group was created in response to the requirement to standardise the definition of a Unix™ operating system.
It achieved this by specifying the behaviours required of the system.
It specified the many (hundreds) of discrete services required of a Unix OS, in an open specification.
The standard specification does not say anything about the internal structure of the OS, or its deployment.
Today, the Open Group’s
vision is to achieve Boundaryless Information Flow™ through
global interoperability of systems.
The original concept of open, vendor-neutral, portable specification of systems
and components remains important
TOGAF was created in response to the requirement (not least in US federal government agencies) to document a messy IT estate and rationalise it.
It proposed each enterprise should specify the behaviours (platform services) required of its IT platform in a Technical Reference Model (TRM).
A TRM does not say anything about the internal structure of platform applications, or their deployment (in-prem or in-cloud).
Today, TOGAF applies the concepts and principles above to both human and computer activity systems.
It encourages vendor-neutral, portable specification, specification of systems and components by required services, and encapsulation of internal structure.
Business goals are decomposed into objectives, some of which lead to requirements for substantial change projects.
Requirements are crystallised in the form of discrete services (ideally service contracts with quantitative measures) before architecture definition.
The rationale is that of component-based design.
Architects define requirements as discrete services, then
assign them to logical roles/components, with a view to hiring/buying/building physical
actors/components.
Architects must decompose large and complex systems into discrete and manageable chunks.
TOGAF divides the descriptions of human and computer activity systems into interoperating components called building blocks.
It presumes architects document baseline and target systems at two levels - architecture building blocks and solution building blocks.
Architecture building blocks are logical or functional specifications of physical solution building blocks.
An architecture building block is named and specified by the services required of it (and a logical data model if appropriate).
One motivation is to maintain open, vendor-neutral, portable specifications of enterprise systems.
Another is to help architects do change impact analysis at a level of abstraction that is shielded from detailed implementation.
TOGAF’s Architecture Development Method (ADM) arranges systems analysis, design and planning activities in a sequence.
On the surface, it proceeds from logical to physical; but this is a somewhat misleading impression.
From the start, architects consider baseline solution building blocks to be used or modified, and potential target solution building blocks.
TOGAF recommends taking account of likely solution building blocks when defining architecture building blocks
It recommends iterating between ADM phases.
And architects may choose to reverse engineer architecture building blocks from known solution building blocks.
In TOGAF, actors are usually humans; in ArchiMate, actors can be organization units as well.
Think of actors as named individuals - solution building blocks in the real world.
These solution building blocks realise more abstract architecture building blocks - logical business functions/capabilities and roles.
Many TOGAF-trained people confuse EA with solution architecture.
For more on the
distinction read Enterprise
architecture versus solution architecture.
TOGAF 7 was about strategic, enterprise-level, IT architecture.
TOGAF 8 was called “the enterprise-edition” and expanded to cover business, data and applications architecture.
TOGAF 9 does describe an enterprise-level architecture using a business function decomposition hierarchy and business/conceptual data model.
However, it has shifted towards being a Solution Architecture project management method, with tangential references to strategic EA.
TOGAF still encourages, supports and facilitates EA.
But the ADM is no longer a process designed specifically for enterprise architects.
It can be used as a solution architecture project management method with or without regard to EA.
(TOGAF authors have used the term "solution" in various ways.
Solution building block specifications are found in the solution continuum and solutions repository.
But that is not what most people mean by solution architecture.
The architecture/solution building block distinction is primarily a logical/physical distinction.
In practice, people in solution architect roles define logical architecture building blocks as well as solution building blocks.
More generally, both kinds of architect (enterprise and “solution”) work at both levels of abstraction - architecture and “solution”.)
The term roadmap is used widely and loosely.
The "architecture roadmap" in TOGAF is not what most real-world enterprise architects mean by an EA-level roadmap.
In theory, when designing and planning any kind of system transformation or change, any kind of architect should
· understand the baseline state,
· define the target state and
· define a migration path for moving systems from baseline to target state.
In practice, enterprise architects do the first two, but not always the last.
Enterprise architects set out landscape-level, long-term roadmaps that cut across ADM cycles.
Solutions architects refer to these higher level roadmaps when defining an architecture roadmap for a specific programme or project.
Thus, solution architecture roadmaps realise the EA-level road maps.
Enterprise architecture is necessarily more abstract than other kinds of architecture.
There are many interpretations of what abstraction means and how to employ the idea.
Idealisation, generalisation and composition are three varieties of abstraction.
Though they are often conflated in practice, they can be separated in theory.
The classical idealisation hierarchy is 3 levels of idealisation, from reality to physical to logical to conceptual.
However, this is interpreted in different ways.
TOGAF plots 3 degrees of idealisation from deployed
solutions against 3 degrees of generalisation from a specific enterprise’s
organisation.
|
Generalisation |
Foundation |
Common system |
Industry |
Organisation |
Specialisation |
|
Idealisation |
Idealisation |
||||
|
Requirements Repository |
Most abstract and universal |
|
|
Most abstract and unique |
Requirements
Repository |
|
Architecture Building Blocks / Repository |
|
|
|
|
Architecture
Building Blocks / Repository |
|
Solution Building Blocks / Repository |
|
|
|
|
Solution
Building Blocks / Repository |
|
Operational Building Blocks in Deployed Solutions |
Most concrete and universal |
|
|
Most concrete and unique |
Operational
Building Blocks in Deployed Solutions |
|
Realisation |
|
|
|
Realisation |
|
|
Generalisation |
Foundation |
Common system |
Industry |
Organisation |
Specialisation |
The OMG’s Model-Driven Architecture features 3 levels of idealisation - from deployed software to PSM to PIM to CIM.
So, it is possible to draw an analogy between MDA and TOGAF.
|
Idealisation |
OMG’s MDA |
TOGAF’s Enterprise Continuum and Repository |
|
Conceptual |
Computation-independent
model (CIM) |
Requirements
& Requirements repository |
|
Logical |
Platform-independent
model (PIM) |
Architecture
Building Blocks & Architecture Repository |
|
Physical |
Platform-specific
model (PSM) |
Solution
Building Blocks & Solutions Repository |
|
Real |
Deployed
software |
Deployed
Solutions [and ITSM CMDB?] |
The mapping in this table is rather misleading.
The CIM in MDA might better be equated to the conceptual/business data model and business function/capability decomposition in TOGAF.
This enterprise-wide CIM sits above any one set of requirements and cycle of the ADM process.
What MDA means by a PIM is a 100% precise model of software than can be transformed by a CASE tool into executable code.
This PIM sits below TOGAF’s solution building blocks, and would not be produced until phase G of the ADM (if ever).
The principle of open, vendor-neutral, portable specifications means that architecture building blocks should be as independent as possible of the vendor/technology platform.
Yes, TOGAF is idealistic in this way - but that is its nature, its position in the world.
"Cloud computing" is mostly about deploying business applications to computers in remote locations.
There are many varieties (private/public/hybrid resources, SaaS/PaaS/IaaS, etc.)
Enterprise architects might define an EA-level principle or standard to employ cloud computing.
This is more a constraint than a requirement, and it would have to more specific to be useful to solution architects.
TOGAF users might capture the constraint in a principles catalog or a standards information base (or an architecture requirements specification).
The constraint may influence architecture building block specifications, but should not be evident in them.
So, you can move solution building blocks between in-prem and in-cloud, without having to change the architecture building blocks.
The constraint will probably be evident in solution building block specifications from ADM phase E onwards.
In TOGAF, architects define requirements as discrete services, and assign
them to logical roles/components, with a view to hiring/buying/building physical
actors/components.
Neither TOGAF, IT4IT nor ArchiMate define "service"
clearly.
They generally discuss or define services as being discretely
requestable behaviors
But it feels like the authors stop short of committing
to that unambiguous definition.
And it doesn't help that what programmers call a "Web
Service" is an interface rather than a service in the above sense.
So, people generate examples in which the label "service"
is given to components, interfaces, and functions/capabilities that bundle discrete
services.
E.g. say a bank provides a banking service - rather than
a variety of discretely requestable banking services.
Or a message broker provides a message service - rather
than a variety of discretely requestable messaging services.
(ArchiMate's definition of a business service is misleading
in this regard.)
Functions/capabilities are hierarchically composable and decomposable - the granularity is up to the system
describer.
Some use the term capability for a high level function
- and use the term function for a low level capability – but this is a hostage to
fortune.
The top, bottom and levels in a hierarchy depend on a)
the scope of the system of interest b) the level of decomposition you stop at.
Functions/capabilities are active structural elements that
can be defined by the services they offer - at any level of granularity you choose.
(ArchiMate's classification of functions as behaviors is
misleading in this regard.)
Services can be coarse-grained or fine-grained - roughly
in proportion to the granularity of the function/capability/system that provides
them.
IT4IT’s description of a functional component is questionable.
“A functional component is the smallest technology unit
that can stand alone and be useful as a whole to a customer”
Hmm…There is no definitively smallest or stand-alone unit
in architecture-level specification, since all is recursive.
Technology units and their “customers” are composable and decomposable just as business functions/capabilities
are.
“A functional component must have defined input(s) and
output(s) that are artifacts?”
Yes, Inputs and outputs are defined in the contracts of
services provided by a functional component.
“A functional component must change or advance a key artifact
(e.g., state change).”
Probably but not necessarily.
A functional component is an active structural element
that can perform behaviors that change that component’s state.
These state changes can be specified in the post conditions
of service contracts.
But only some behaviors change or advance component
state, some merely report on it.
(Each behavior advances incrementally along
a thread of control, but little or none of this history is persisted in state.)