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

Preface. 1

Patterns in TOGAF’s architectural specification. 1

Direct and indirect relationships between architectural entities. 3

The logical / physical dichotomy. 3

 

Preface

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.

Patterns in TOGAF’s architectural specification

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.

Direct and indirect relationships between architectural entities

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 dichotomy

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.

Read TOGAF – business capabilities and functions for more detail about relationships in the business architecture meta model.

 

 

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 (read this paper for evidence).

Basic system theory is partially obscured behind the TOGAF narrative, yet it is there all the same.

For more detailed analysis go to the http://avancier.website

.

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0           18/08/2013 11:18

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.website” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see  http://creativecommons.org