TOGAF
– general patterns and principles – architectural specification
This page is published under the
terms of the licence summarized in the footnote.
All free-to-read materials on the Avancier web site 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.
This is the first of four related papers at http://avancier.website.
Contents
Patterns
in TOGAF’s architectural specification
Direct
and indirect relationships between architectural entities
The
logical / physical dichotomy
EA design sequences (recommended in TOGAF and ArchiMate) reflect system theory principles:
· From logical to physical - abstract specification before concrete implementation.
· From external to internal - required services/products before internal processes and roles/actors/components.
· From behaviour to structure - services and process sequences before roles/actors/components.
· From business to technology - human actors before computer actors.
There are reasons to deviate from these sequences in practice, and to “reverse engineer”.
But methods for governing design and implementation against a specification usually start with these presumptions.
This paper introduces patterns TOGAF applies to specification documentation and to design processes.
EA is about business capabilities, about human and computer activity systems in which actors/components have the ability to achieve desired effects by playing roles in processes.
A required capability can be specified as group of required services (accessible via interfaces) to be delivered by actors/components able to perform the necessary processes.
This table maps terms commonly used in business and software architecture to a general structure.
|
General structure |
General concepts |
General business architecture
entities |
General software entities |
|
Active structure |
Actors/components play roles in |
Actors, Roles |
Objects, Classes, Components |
|
Behaviour |
processes to |
Business Processes |
Method bodies, Procedures |
|
Passive structure |
maintain system state and/or |
Business Data Entities |
Fields, Attributes |
|
Boundary |
interact via inputs and outputs with each other and with |
Business Services/Products Service Level Agreements |
Methods, Operations, Interfaces |
|
Environment |
external
entities and events |
Customers,
Suppliers |
Client and
server objects |
Specification by encapsulation of capabilities, systems or
components is a fundamental principle, predating SOA and OO design.
Service-oriented specification has been a principle of The Open Group since it
was formed, and underpins TOGAF.
The table below applies a general pattern to architectural entities in the TOGAF meta model.
|
Passive Structure |
External Behaviour |
Internal Behaviour |
Logical Active Structure |
Physical Active Structure |
|
|
Generalisation |
Object |
Service |
Process |
Logical Component |
Physical Component |
|
Business |
Event,
Product |
Business
Service |
Process |
Function |
Organisation
Unit |
|
Role |
Actor |
||||
|
Information System |
Data
Entity |
Information
Service |
|
Logical
App Component |
Physical
App Component |
|
Technology |
|
Platform
Service |
|
Logical
Tech Component |
Physical
Tech Component |
You can specify a Logical Component by naming it and specifying its Interface, which means listing the discrete Services it offers in its “service portfolio”.
· A "Logical Technology Component" is specified by the "Platform Services" it offers.
· A "Logical Application Component" is specified by the "Information System Services" it offers.
· A business “Function” or “Role” can be specified by the "Business Services" it offers.
The TOGAF meta model shows
these direct left-to-right associations.
·
Information Services <are assigned to>
Logical App Components <are realised by> Physical App Components
·
Platform Services <are assigned to>
Logical Tech Components <are realised by> Physical Tech Components.
These additional indirect associations are valid, but
TOGAF omits them.
·
Information Services <are assigned to--<
Physical App Components
·
Platform Services <are assigned to>
Physical Tech Components.
In the business domain, the direct left-to-right
associations are:
·
Business Services/Products <result from>
Processes <are clustered into> Functions <are assigned to--<
Organisation Units
·
Business Services/Products <result from>
Processes <involve> Roles <are played by> Actors.
EA documentation is usually centred on a logical
functional decomposition hierarchy aka capability map.
This decouples
the logical architecture from the organisation’s management structure.
These additional indirect associations are valid,
but fragile due to the volatility of organisation structures and employees.
·
Business Services/Products <are produced by>
Organisation Units
·
Organisation Units <employ> Actors
·
Processes <are performed by> Actors.
One more association, Business Services/Products
<are assigned to> Functions, is relevant.
Since Functions can be defined externally by the
Services they offer and internally by the sub-Functions they contain.
The logical / physical distinction may be drawn in several different ways; some equate it to the behaviour / structure distinction.
This table maps the logical / physical distinction in TOGAF to the external / internal distinction in ArchiMate/BCS generic meta model.
|
ArchiMate/BCS generic meta model |
|
|
TOGAF meta model entities |
||||
|
Behavioural view |
Structural view |
. |
. |
|
Behavioural view |
Structural view |
|
|
External view what external entities see |
Event / Service |
Interface |
|
|
External & Logical |
Business Service IS Service Platform Service |
Function/Capability, Role Logical Application Component Logical Technology Component |
|
Internal view the workings of the system |
Process |
Component |
|
|
Internal |
Process |
Organisation,
Actor Physical
Application Component Physical
Technology Component |
EA describes human
and computer activity systems in which actors/components play roles in
activities.
Note that TOGAF architects describe both logical actors/components and physical realisations/instances of them.
(They describe logical Services and Processes, but cannot describe physical realisations/performances of them, since they exist only at run time.)
Physical Component descriptions are technology-specific, but still “considerably abstracted from” deployable physical artefacts.
Specifications of Physical Components and other Solution Building Blocks are recorded in TOGAF’s solution repository
Specifications of even more abstract Logical Components and other Architecture Building Blocks are recorded in TOGAF’s architecture repository.
Most meta model entities (e.g. Components, Processes, Services and Goals) are composable and decomposable.
Recursive composition and decomposition of these elements means that most associations between them are N-N.
Related papers
In 2008, I had to align TOGAF with ArchiMate, UML and several other sources, to complete work commissioned by the British Computer Society.
It seemed well-nigh impossible until I recognised General System Theory concepts in the ArchiMate generic meta model, and realised this theory provided a neutral middle ground.
General System Theory underpins EA at all levels; it is partially obscured behind the TOGAF narrative, yet it is there all the same.
For more detailed analysis go to system theory page at http://avancier.website
.
Footnote: Creative Commons Attribution-No
Derivative Works Licence 2.0 18/08/2013 11:18
For
more information about the licence, see http://creativecommons.org