TOGAF
– general patterns and principles – architectural design processes
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 second of four related papers at http://avancier.website.
Contents
Patterns
in TOGAF’s architectural specification
The general
process for formalisation or digitisation of capabilities
The
general process for rationalisation of a messy system estate
The
general process for designing and changing a business capability in a cycle of
ADM
What
about data / information architecture?
TOGAF and ArchiMate presume the design of a capability, function or system runs:
· from abstract to concrete - logical specification before physical implementation
· from external to internal – required services/products before internal processes and roles/actors/components
· from behaviour to structure – sequences and process sequences before roles/actors/components.
And for enterprise architecture, they add another sequence: from business to technology - human actors before computer actors.
There can be reasons to deviate from these sequences in practice.
But methods for governing design and implementation against a specification usually start with these presumptions (which reflect General System Theory principles).
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.
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.
Read TOGAF – business capabilities and functions for more detail about relationships in the business architecture meta model.
Many people don’t seem to realise that TOGAF defines Services in the architecture requirements specification outside and before defining Processes and Components in the architecture definition document.
This reflects the natural design sequences mentioned in the preface above.
The design processes used in TOGAF are generalised below.
This process can be generalised as:
Design the target
1. Define required Services
2. If need be, design Processes to deliver the required Services.
3. Assign required Services and/or Process steps to logical Interfaces, Functions or Roles.
4. Change, hire, buy or build physical Actors/Components to realise logical Interfaces and perform process steps.
This process can be generalised as:
Analyse the baseline
1. Catalogue baseline Actors/Components (org. units, functions, roles or actors).
2. Abstract the discrete Services provided by those baseline Actors/Components.
3. De-duplicate baseline-provided Services
Design the target
5. Define required Services
6. If need be, design Processes to deliver the required Services.
7. Assign required Services and/or Process steps to logical Interfaces, Functions or Roles.
8. Change, hire, buy or build physical Actors/Components to realise logical Interfaces and perform process steps.
The ADM interleaves three natural design sequences: external before internal, behaviour before structure, and business before IT.
Business architecture
· Define new/changed business services required.
· Define logical business processes and/or functions to provide required business services.
· Define business roles to perform elementary business process steps and/or business functions.
· Change, hire, buy or build organisation units to manage business roles (revise business organisation structure as need be).
Information system architecture
· Define new/changed information system services (use cases) required.
· Define I/O data flows (in service contracts or use case headers) and data stores.
· If need be, define logical application processes (as in use case paths)
· Change, hire, buy or build physical applications to support and enable logical use cases (revise business application portfolio as need be).
Technology architecture
· Define new/changed platform services required (revise the TRM as need be).
· Don’t define logical platform processes, since they are given by vendors behind APIs.
· Hire or buy physical technologies to provide required APIs (revise technology component portfolio as need be).
Business
systems can be seen as formalised social systems.
Businesses created and used
data long before computers
In ancient Egypt, business
data was written to and read from clay tablets.
Business communication requires
formalization of data types used in messages and data stores.
In theory, data
architecture is part of every other architecture domain
Since business
capabilities were computerised there have been:
(1) data flows between human roles (oral,
on paper forms, in emails...).
(2) data flows between human roles and business
applications (HCI or UI).
(3) data flows between business applications
(point to point, or via middleware)
(4) data flows between business applications and
platform applications (notably databases)
(5) data flows between platform applications.
Data
or information?
The terms “data” and “information” are used loosely and
interchangeably in many contexts.
Life is too short to debate
the many different distinctions that people draw between these terms.
One tradition in EA
frameworks is that information is data at the point of creation
or use by humans (level 2 above).
Data is what appears only
within the computer activity system (levels 3, 4 and 5 above).
It can be said that information is more than data; it is the application of a language (data types and grammar) to data by an actor who creates or uses that data.
Read Information Theory for more; but we’ll stick with “data” here.
In practice, data architecture is about handled by
business applications
The focus of data
architecture in EA is on business data that is digitised
or digitisable (levels 2, 3 and 4 above.)
And so, data architecture
is wrapped up with “application architecture” under “information systems
architecture”.
Note: data
is plural, and it should be applications
rather than application.
Data flow or interface?
Data flows are called interfaces in what TOGAF calls an interface catalogue (at level 3 above).
But nowadays the term interface is more usually a list of services provided or required.
Defining data to support
Information System Service definition
Information System Services may be defined in form of “use
case descriptions”.
A use case description records a Process (main and exception paths) wrapped up
inside a service contract.
You might simply name core use cases and map them to business Roles, Processes
or Functions.
Suppose you need to specify the use case in detail, with inputs, outputs, pre
and post condition?
Then you need to define a logical data model also, in order to define the
business-specific terms and concepts used in service contract or use case
description.
That logical data model may act as a specification for a physical data store.
Data flow or service?
Data flows are probably the most important entity not mentioned explicitly in the TOGAF meta model.
The meta model includes data components (data store structures) but not data flows.
It may be assumed input and output data flows are defined inside service contracts (for business, information system and platform services).
But do people want to create a service every time they want to define a data flow?
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