TOGAF uses of abstraction
One of more than 300 papers at http://avancier.website. Copyright Graham Berrisford. Last updated 24/08/2017 20:52
The earlier Architecture and Design paper identified nine kinds of abstraction
This paper identifies where six of those abstraction varieties are used in TOGAF.
Contents
Abstraction
by encapsulation of system behaviour, structure and data
Abstraction
by separation of parallel views
Abstraction
by delegation from clients to servers
Abstraction
by generalisation and idealisation
Can
an architecture be technology independent?
There are two basic kinds of abstraction:
1. Abstraction from reality (physical matter
and energy) to description of it.
2. Abstraction of description - from more
detailed descriptions/models to less detailed ones, sometimes called
architectures.
This table illustrates the first - abstraction from reality to description of it.
Abstraction in system theory |
System descriptions/models <create and
use> <abstract
from> System describers <observe and envisage
> Systems in operation |
The second definition masks many varieties of abstraction.
Zachman proposes architects abstract from detailed designs in one particular way called idealisation
In practice, architect use several kinds of abstraction at once, both consciously and unconsciously, when describing an operational system.
They may abstract in these ways more by artistic intuition than by scientific reasoning, but skilled architects do consciously manipulate them.
For example, the table below (copied from the TOGAF-ArchiMate alignment slide show) shows four kinds of abstraction used in TOGAF.
EA
domains |
EA levels |
Enterprise
Continuum scales |
|
Delegator |
Composition |
Generalisation |
Idealisation |
Business Information
Systems Technologies |
Enterprise/Strategy Segment Capability |
Foundation Common System Industry Organisation |
Requirements Architecture
continuum Solution
continuum Deployed
solutions |
Servant |
Decomposition |
Specialisation |
Realisation |
The Open Group’s Architecture Framework (TOGAF) is a management framework for work to change business systems.
It is focused on the architectural definition of business systems – not necessarily enterprise level or enterprise wide.
It is generalised sufficiently that it may be used at different levels of scope or composition.
It suggests architecture definition may be done at three levels of scope and detail.
And implies a one-to-many composition relationship between a higher and lower level in this structure.
Composition |
Enterprise/Strategy Segment Capability
(increment) |
Decomposition |
The Open Group use this idea in defining open standards.
They define the open standard for the operating system called UnixTM by defining the discrete services required of it.
TOGAF defines systems, “building blocks” and “components” by defining the services required of them.
The table below is a simplified version of what you can find in the TOGAF-ArchiMate alignment slide show.
TOGAF |
Required
behaviours |
Building
Blocks |
External view |
Services |
|
Internal view |
Roles/Components |
Services typically consume some input data and produce some output data.
Business systems store some of the input data for future use.
Business system architects must address the location(s), confidentiality, integrity and availability of stored data.
Architects commonly define parallel views of a system, each view omitting details found in the other views.
TOGAF proposes building a library of “viewpoints”, defining how and why to draw different views for different stakeholders
Architects often simplify a complex system by organising it into a hierarchy of client and server layers.
Clients abstract from servers by delegation - by requesting services without knowledge of the servers’ internal structure or workings.
This idea is used in network architectures, software architectures and business architectures.
ArchiMate presents the primary enterprise architecture domains as client-server layers.
Delegator |
Business Applications Technologies |
Servant |
The table below is a simplified version of what you can find in the TOGAF-ArchiMate alignment slide show.
ArchiMate |
Behaviour
elements |
Active
structure elements |
|
TOGAF |
Service
portfolios |
Architecture
building blocks |
Solution
building blocks |
Business |
Business Services |
Functions, Roles |
Organisation Units, Actors |
Applications |
IS or Application Services |
Logical Application Components, Interfaces |
Physical Application Components |
Technologies |
Platform or Technology Services |
Logical Technology Components, Interfaces |
Physical Technology Components |
TOGAF expects architects to comply with generic reference models, design patterns, principles and standards.
And to look for what is general to an industry (say telecoms), general to a function (say accounting) and common to all (say, email).
TOGAF’s “enterprise continuum” classifies system elements using both generalisation and idealisation.
Generalisation |
Idealisation |
Foundation Common System Industry Organisation |
Requirements Architecture
continuum Solution
continuum Deployed
solutions |
Specialisation |
Realisation |
TOGAF plots 3 degrees of idealisation (bottom to top) from
deployed solutions against 3 degrees of generalisation (right to left) from a
specific enterprise’s organisation.
|
Generalisation |
Foundation |
Common system |
Industry |
Organisation |
Specialisation |
|
Idealisation |
Idealisation |
||||
|
Requirements
|
|
|
Requirements Repository |
||
Logical |
Architecture
Building Blocks |
Vendor-neutral / standard |
|
|
Vendor-neutral / unique |
Architecture Repository |
Physical |
Solution
Building Blocks |
Vendor-specific /
standard |
|
|
Vendor-specific / unique |
Solutions Repository |
Real |
Operational
Building Blocks |
|
|
Deployed solutions |
||
|
Realisation |
|
|
|
Realisation |
|
|
Generalisation |
Foundation |
Common system |
Industry |
Organisation |
Specialisation |
In TOGAF, architecture building blocks are documented descriptions of system elements that support or enable the provision of business services.
Rather than contrast architecture with design, TOGAF draws a dividing line between architectures and “solutions”.
It proposes architectures are abstracted idealisation from “solutions” in very particular way.
Architects in phases A to D define architecture building blocks in a vendor-independent way.
That doesn’t mean they ignore vendors or the technologies they sell.
It means only that they strive to document and maintain vendor-neutral specifications of required systems and components.
In phases E to G, they select or define vendor-specific solution building blocks to implement the logical architecture building blocks.
This way of distinguishing the terms “architecture” and “solution” seems peculiar to TOGAF.
Outside of TOGAF, it is common to define an architecture that is vendor specific.
For more on the term “solution architecture”, read the companion “Enterprise versus Solution Architecture” paper.
This last section of this paper distinguishes vendor-independent from technology independent.
Some say an architecture should be technology-independent. What does that mean? And is it true?
An architecture is an abstract design of a new thing, or description of an existing thing.
The most definitive version of an architecture is to be found in approved documentation.
A technology is a machine or device manufactured to assist or enable an activity.
An information technology is a technology made to assist or enable a data processing activity.
Business roles and processes have always been shaped by the information technologies available.
Since the start of the “information age”, business roles and processes have depended on digital information technologies.
Enterprise and solutions architects have to understand what technologies can do for business actors.
At the same time, they want to minimise the technical detail in architecture documentation presented to clients.
Some say architecture definitions should be idealised or
logical in the sense of being technology
independent.
The fact is, every professional architect has to understand the
capabilities and capacities of technologies their architecture depends on.
If they don't,
and things go wrong, they should be sued for lack of due diligence.
(In the absence of litigious clients, amateur architects can get away with murder.)
The graphic below may be misread to imply a business architecture is independent of infrastructure technology.
Clients delegate to servers, but also depend on them.
You cannot design a client layer with no understanding of what its server layer(s) can do.
Cient-server hierarchy |
Architecture
domain layers |
|
Client layer |
Business architecture |
Business roles,
processes and services |
Server and Client layer |
Information system architecture |
Business
applications and services |
Server layer |
Infrastructure technology architecture |
Platform
technologies and services |
A business architect has to make presumptions about what technologies do to support and enable business roles, processes and services
Modern business processes depend on the use of client devices, data servers, local and/or global networks.
Customer behavior is affected by whether the enterprise can roll back a failed business transaction using transaction manager.
In short, most if not all enterprise architecture definition depends on some or other information technology.
For more: on
abstraction of description from reality, architectures from systems, read “Architecture versus system”:
On the distinction between enterprise and solution architecture”, read “Enterprise and Solution”.