TOGAF principles and concepts

Featuring building blocks and services.

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 12/12/2017 00:25

ArchiMate®, The Open Group®, TOGAF®, UNIX®, are registered trademarks, and Boundaryless Information Flow™ and IT4IT™,  are trademarks of The Open Group.

 

Synchronising the core vocabulary within and between standards is a challenge.

But the task is not hopeless; as this paper shows.

This is one of several papers - based on analysis done for the British Computer Society.

Contents

Structures and behaviors in system description. 1

Some TOGAF principles. 3

Core TOGAF concepts. 5

Services. 7

Building blocks. 8

Aligning ArchiMate and TOGAF meta models. 9

More about building blocks. 10

More about behaviors. 11

More about structural elements. 12

Footnote 1: Where some of the principles appear in TOGAF. 13

Footnote 2: a few curious facts. 14

 

Structures and behaviors in system description

System modelling standards such as UML and ArchiMate draw a distinction between structures and behaviors.

The table below illustrates the distinction by pairing off various terms – terms highlighted in blue are used in TOGAF and in this paper.

 

Structures and stocks in space;

components related in hierarchies and networks

Behaviors and flows in time;

events and activities in sequences

Actor

Building block

Capability

Dancer

Entity

Function

Holding

Matter

Organisation unit

Player

Product

Role

Stock

Trader

Structure

Variable and Value

Activity

Behavior

Conduct

Dance

Event

Flow

Happening

Motion

Operation

Performance

Process

Rule

Stream

Transaction

Service

Value Stream

 

Every designed system can be described in terms of structures that perform some behaviors to meet some aims.

This table generalises from how these concepts appear in standard frameworks like TOGAF and NAF, and modelling languages like ArchiMate and UML.

 

Business system concepts

General definitions

Aims (why)

motivations for behavior

Goal or Objective

a target to be achieved, a motivation or reason to perform behaviors.

Behaviors (how and when)

things that happen over time and change the state of a system or its environment

Service

a discrete requestable behavior that produces a result of value to a consumer, describable in a contract that encapsulates internal processes

Process

a sequence of activities that leads to the production of a desired result (a state change, product or output flow).

Logical structures

groups of behaviors that are assignable to active structures

Function

a logical system component, describable externally by services provided and internally by activities assignable to one or more organisation units.

Role

a logical system component, describable externally by services provided and internally by activities assignable to one or more actors.

Active structures (who)

things that act - perform behaviors

Organisation unit

a named business division, which can be given the responsibility of realising one or more logical functions.

Actor

a named person or machine, which can be given the responsibility of realising one or more logical roles.

Passive structures (what)

things that are acted on

Physical entity

a concrete entity type that a business creates and/or uses in the course of performing behaviors.

Data entity

a record type that describes the attributes of an entity or event, which is created and used in the course of performing behaviors.

Location (where)

a place in space where a structure can be found.

 

Aside: in UML, roles are called actors; in the ArchiMate standard, both people and organisation units are called actors; the table above separates people from organisations and roles.

And note the curiosity that whereas every human actor is a unique individual, every software actor is a replicable individual.

 

The table below shows the TOGAF standard is (and has always been) thoroughly service-oriented.

All architecture domains and building blocks within them are defined by the services they offer.

 

Generic entities

TOGAF entities

Business

Applications

Technology

Required behaviors

Services

Business Services & Processes

IS/Application Services

Platform/Technology Services

Logical structures

Architecture Building Blocks

Functions & Roles

Logical Application Components

Logical Technology Components

Physical structures

Solution Building Blocks

Organisation Units & Actors

Physical Application Components

Physical Technology Components

Core TOGAF concepts

The table below shows how TOGAF concepts can be related in a coherent and consistent whole.

The purple indicates terms and/or concepts in other sources.

 

Bear in mind the highly iterative and flexible nature of the ADM.

Reading the ADM from start to end can leave people with misconceptions - addressed in notes below the table.

 

ADM

Iterative!

Deliverables

Enterprise Continuum

Enterprise Repository

Specifications of

Services and BBs

Business

domain entities

Applications

domain entities

Data

domain entities

Technology

domain entities

Zachman’s

levels

System theory ideas

(Ackoff, Ashby etc.)

A onwards

Architecture Requirements Specification

Requirements and Context

Requirements Repository

Business & Application

Service Contracts

Business Services

Application

IS Services

 

Technology Services

(TRM, SIB)

Scope

Behaviors

A to D

and onwards

Architecture Definition Document

Architecture Continuum

Architecture Repository

Architecture

Building Blocks

Processes and Roles

Functions

Logical

Application

Components

Data Entities,

Logical Data

Components

Logical

Technology

Components

Conceptual

Logical

Abstract

system description

E to G

Architecture Road Map

Solutions Continuum

Solutions Repository

Solution

Building Blocks

Organisation Units,

Actors

Physical

Application

Components

Physical

Data

Components

Physical

Technology

Components

Physical

Concrete

system description

H

Deployed Solutions

Identity Management

IT Configuration Management

Configuration

Concrete system

realisation

Business and IT Operations

Instantiation

 

Note 1: TOGAF does not dictate a sequence from top to bottom.

E.g. Business structure artifacts that may be produced before an ADM cycle include functional decomposition, organisation decomposition and business scenarios.

As TOGAF says: “as a free-standing exercise, either preceding architecture development, or as part of Phase A."

TOGAF suggests using functional decomposition for heat mapping and scoping changes planned via an ADM cycle.

 

Note 2: TOGAF does not imply the three sections of the enterprise repositories are disconnected

The reverse is true, architecture building blocks are traced to requirements.

And solution building blocks must be cross-referenced to architecture building blocks.

 

Note 3: TOGAF does not prevent you knowing or defining technology solutions while working on the products of phase A to D.

E.g. Phase A might start with a request to implement a particular application or technology solution within one organisation unit.

That does not mean documenting that solution in the requirements repository or architecture repository.
It simply means starting phase E early and populating the solutions repository with the (likely) solution building block.

The TOGAF principle is to define that solution in a logical (implementation-independent, vendor-neutral, portable) architecture definition

Not least because it is that (rather than solution documentation) which enterprise architects maintain in phase H: “architecture change management”.

 

Note 4: The blue elements may appear in the definition of business scenarios (cf. value streams).

EA looks to standardise, integrate, optimise and innovate in business processes and roles that create and use business data.

TOGAF recommends starting from the products and services needed to achieve business goals.

And defining the “architecture vision” by documenting business scenarios that deliver those products and services.

A business scenario outlines a business process and the roles of human and computer actors in it (cf. value streams).

 

Note 5: Where do “capabilities” and “value streams” fit?

TOGAF's generic function and process concepts are infinitely composable and decomposable.

So, you can see “capabilities” and “value streams” as corresponding to high-level functions and processes.

True, capabilities cluster abilities whereas functions cluster activities, but their use in a methodology is well nigh identical.

E.g. capability maps are like functional decomposition diagrams in appearance, purpose and practical use.

That is why TOGAF 9.1 does regard capabilities as corresponding to high-level functions.

It could also present value streams as high-level processes, but then, where would that leave TOGAF's business scenario?

 

There are c5,000 words in TOGAF on business modelling.

But they are largely ignored in separately-written TOG guides on business architecture.

And importing terms and concepts from other business architecture standards into TOGAF without care will create new incoherence and inconsistency.

The place of capabilities and value streams in TOGAF is further discussed in this paper.

Some TOGAF principles

The principles below are not declared as such in the standard text.

Nevertheless, their appearance and reappearance helps to give TOGAF coherence and consistency.

 

1: Enterprise as a system of interacting building blocks

“EA regards the enterprise as a system, or systems of systems”

“Systems are built up from … building blocks [that] interoperate with other building blocks.”

The major work… consists of identifying the architecture building blocks required to meet the business goals and objectives.”

Below, you can read building block as function, role, organisation unit or component.

 

2: Architecture building blocks abstract from implementation

 “The architect… must remain at a level of abstraction necessary to ensure that they do not get in the way of practical implementation.”

“Logical application component: an encapsulation of application functionality that is independent of a particular implementation.”

“Physical elements  may still be considerably abstracted from solution architecture, design, or implementation views.”

Solution building blocks are hired, bought or built to realise architecture building blocks, and so perform the required behaviors.

 

3: The primacy of behavior in building block specification

This means the internal structure of a building block is secondary to its behaviors.

A building block provides services that deliver results of value to other building blocks and/or external entities.

“For each building block, build up a service description portfolio as a set of non-conflicting services.”

 

4: Freedom to abstract and to refine

To enable this, most system description elements (not just functions and processes) can be hierarchically nested.

So, systems descriptions can be composed and decomposed to suit the breadth of the system, and level of detail required.

Also, elements can generalised and specialised, according to the standardisation and/or diversification required.

And so, every concept used in system description can be composed and/or decomposed; and be generalised and/or specialised.

 

5: Rationalisation by reverse/forward engineering

This means: reverse engineer from physical structure to logical structure and current behavior.

Then forward engineer from required behavior to logical structure to physical structure.

This principle, though the whole basis of TOGAF v1 to 7, is ss clear in v9.

 

6: The generic meta model

A general pattern, evident in the meta model, is reflected in many parts of TOGAF.

Required behaviors <are assigned to> logical building blocks <are realised by> physical building blocks.

 

EA involves analysing and describing the human and computer activity systems in a business.

The UML standard sets out two premises that underpin the modelling of all such business systems.

1.      all behavior in a modeled system is ultimately caused by actions executed by so-called active objects.” (cf. building blocks in TOGAF).

2.      behavioral semantics only deal with event-driven, or discrete, behaviors.” (cf. services in TOGAF).

These two premises appear in TOGAF in the form of services and building blocks, discussed below.

Services

“The method proposed by systems theory is to model… multiple interacting components by abstracting from certain details of structure and component.” (Laszlo and Krippner)

To define the services provided by one or many components is to abstract from the details of their internal structures, interactions and resources

This table below quotes definitions of service in two Open Group standards, and generalises from them.

 

A service as defined in TOGAF 9.1

A service in ArchiMate 3.0

A service - in general terms

“an element of behavior that provides specific functionality

a unit of behavior

a discretely requestable behavior (short or long) that

in response to requests from actors or other services.”

“useful to its users”

is triggered by an event/input received from a service requester/consumer.

“A logical representation of a repeatable business activity,

realized by.. functions.. performed”

encapsulates repeatable internal processes,

has a specified outcome,

“associated with a value”

produces a result of value to a service requester/consumer, and is

is self-contained, is a ‘‘black box’’ to its consumers.”

accessed through one or more… interfaces.”

presented to service requester/consumers in one or more interfaces.

 

A service is a logical representation of a repeatable activity that has a specified outcome.

A service is first named, then lightly described, and eventually defined in a service contract.

A service contract makes no reference to the internal workings of any building block that provides it (or other building blocks it depends on).

 

TOGAF’s ADM is a method for service-oriented architecture development.

·         In phases B and C, Business and IS Service Contracts are recorded in the Architecture Requirements Specification. 

·         In phase C, the III-RM provides a service-oriented design pattern for the applications architecture domain/layer. 

·         In phase D, the TRM catalogues the foundation Platform Services provided by the technology architecture domain/layer.

 

These three phases populate the Architecture Continuum and Architecture Repository with Architecture Building Blocks defined by the services they offer.

Building blocks

TOGAF defines a component as a building block - an encapsulated component of functionality or capability – in accord with component-based design principles.

TOGAF's building block chapter mirrors the section in the UML standard on the more universal "component" concept.

Note the usual terminology hell.

·         UML component = TOGAF building block (business function, role, application or platform technology etc).

·         UML service = TOGAF boundary or interface.

·         UML operation = TOGAF service (a discrete behavior in service portfolio, which may be offered via an interface).

 

Quotes from TOGAF’s definition of Building Block (Chapter 37)

Quotes from UML 2.4.1 / 8.3.1. definition of Component

An architecture is a set of building blocks depicted in an architectural model, and a specification of how those building blocks are connected to meet the overall requirements of the business.

 

A building block is a package of functionality defined to meet the business needs across an organization.

 

A component represents a modular part of a system that encapsulates its contents.

A component is a self-contained unit that encapsulates the state and behavior of [internal elements].

Systems are built up from collections of building blocks,

so most building blocks have to interoperate with other building blocks.

A system’s functionality may be assembled by reusing components as parts in an encompassing component or assembly of components, and wiring them together.

(UML stereotypes include «subsystem» to model large-scale components.)

it is important that the interfaces to a building block are published and reasonably stable.

A component defines its behavior in terms of provided and required interfaces

Ideally a building block is re-usable and replaceable

A component is a substitutable unit that can be replaced ... by a component that offers equivalent functionality.

and well specified.

A component specifies a formal contract of the services that it provides to its clients and those that it requires from other components in the system.

 

A system can be extended by adding new component types that add new functionality.                               

A building block has a defined boundary and is generally recognizable as ‘‘a thing’’ by domain experts.

A component has an external or “black-box” view by means of its publicly visible properties and operations.

A building block may be assembled from other building blocks;

may be a subassembly of other building blocks.

A component also has an internal or “white-box” view [that] shows how the external behavior is realized internally.

A building block may interoperate with other, inter-dependent, building blocks.

The wiring between components in a system can be structurally defined by using dependencies.

It should be possible to realize a building block in several different ways without impacting the boundary or specification of the building block.

A building block’s boundary and specification should be loosely coupled to its implementation.

UML stereotypes [applied to component include] «specification» and «realization»

where one specification may have multiple realizations.

The major work… consists of identifying the architecture building blocks required to meet the business goals and objectives. The selected set of architecture building blocks is then refined in an iterative process

A component is modeled throughout the development life cycle and successively refined into deployment and run-time.

to arrive at a set of solution building blocks which can either be bought off-the-shelf or custom developed.

A component may be manifest by one or more artifacts, and in turn, that artifact may be deployed to its execution environment.

 

A deployment specification may define values that parameterize the component’s execution.

Aligning ArchiMate and TOGAF meta models

In seeking to align the vocabularies of the two standards it is hopeless to tackle the terms in their vocabulary one by one.

Because the axioms on which the two standards are based are a little different.

We have to step back to consider the generic principles that underpin the standards.

 

ArchiMate generic meta model - simplified

 

Behavior

Structure

External view

Service

Interface

Internal view

Process

Active Structure

 

TOGAF sets out the ideal of separating logical specification from physical realisation.

It separates logical active structures from the physical structures that realise them.

·         "Logical: An implementation-independent definition of the architecture."

·         "Physical: A description of a real-world entity." 

 

ArchiMate adapted to fit TOGAF

 

Behavior

Structure

External view

Service

Interface

Internal view

Process

Logical Active Structure

Physical Active Structure

 

Logical structures aggregate properties (e.g. abilities and behaviors) that physical structures are expected to realise.

Physical structures are nominated to realise those properties (e.g. perform those behaviors.)

 

TOGAF version of the same

 

Behavior

Structure

Generic meta mdoel

External view

Service

Interface / Boundary / Service portfolio

Required behaviors

Internal view

Process

Logical Architecture Building Blocks

Logical structures

Physical Solution Building Blocks

Physical structures

 

Architecture building blocks aggregate properties (e.g. abilities and behaviors) that physical building blocks are expected to realise.

Physical building blocks are nominated to realise those properties (e.g. perform those behaviors.)

 

The core of the TOGAF meta model

The TOGAF meta model is not designed to be a picture for untrained people, or to be a CASE tool database schema.

It is a highly generalised model, designed to highlight principles in the TOGAF methodology.

·         "Logical: An implementation-independent definition of the architecture."

·         "Physical: A description of a real-world entity." 

 

 

Required behaviors

Logical structures

Physical structures

Business

Business Services

Functions

Organisation Units

Roles

Actors

Information Systems

IS Services

Logical Application and Data Components

Physical Application and Data Components

Technology

Platform Services

Logical Technology and Components

Physical Technology Components

 

More about building blocks

System theory is based on defining a system at an abstract level as a collection of interoperating subsystems, here called building blocks.

It defines a building block as an encapsulated component of functionality or capability – in accord with component-based design principles.

 

An abstract/logical building block (function, role, logical component) clusters cohesive behaviors (services offered and/or activities performed) that concrete building blocks can be nominated to perform.

A concrete/physical building block (organisation unit, actor and physical component) is nominated or assigned to perform instances of behavior types.

 

TOGAF expresses the importance of encapsulating building blocks.

“Systems are built up from collections of building blocks, so most building blocks have to interoperate with other building blocks.”

“It is important that the interfaces to a building block are published and reasonably stable.”

 

TOGAF tends to use the terms boundary and service portfolio instead of interface.

It encapsulates structural building blocks by defining the services they are required to perform.

“For each building block, build up a service description portfolio as a set of non-conflicting services.”

“A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports, etc.)”

 

Building block specification progresses through the ADM.

1.      Phase A: “At an early stage, a building block can simply consist of a name or an outline description."

2.      Phases B, C & D: “A building block’s boundary and specification should be loosely coupled to its implementation”

3.      Phases E, F & G: “It should be possible to realize a building block in several different ways without impacting the boundary or specification of the building block.”

4.      Phase H: “In many cases the architecture [ABBs] continues to fit, but the solutions [SBBs] underlying them may not, and some changes are required.”

 

Note that architecture building blocks (ABBs) abstract from solution building blocks (SBBs).

“The method proposed by systems theory is to model complex entities (multiple interacting components) by abstracting from certain details of structure and component.” (Laszlo and Krippner)

More about behaviors

Service: a discretely requestable behavior that encapsulates one or more processes; it is triggered by an event or service request and produces a result of value; and is definable declaratively in a contract.

Process: a behavior composed of steps in a sequence; it is triggered by an event or service request and leads to an interim or final result.

 

Structural elements and behavior elements can be related in value stream diagrams, use case diagrams, sequence diagrams and other process models.

Services

“The importance… of specifying the desired behavior of a system before designing the structure that has to provide it, was the reason to include this concept in ArchiMate.” Mark Lankhorst.

Examples in the framework include: Check customer credit, Provide weather data, and Consolidate drilling reports.

Examples in the Modelling Language include: Policy Creation, Claim Registration, and Claim Payment.

 

Service contracts

The term service appears 1,037 times in the framework; and (as in rest of the industry) the term is used inconsistently.

However, the definition in chapter 22 says services are repeatable behaviors with specified outcomes.

"A service is a logical representation of a repeatable business activity that has a specified outcome”

It is “self-contained - may be composed of other services - is a ‘‘black box’’ to consumers of the service.”

The meta model chapter says a contract covers:

·         Behavior characteristics: functional behavior supported

·         Names of consumer and provider services.

·         Quality characteristics: non-functional requirements

 

In general, a service contract should include:

·         signature (name, input and output)

·         functional rules (pre and post conditions)

·         non-functional requirements.

 

Common errors include:

·         Naming a component or interface as a service (don’t call it a web service or micro service, call it a web app or micro application component).

·         Defining a group of services as one service (better call it a function, or assign it for access to an interface).

·         Turning a noun into a gerund (don’t say a hairdresser provides a hairdressing service, or a message broker provides a messaging service).

 

Read this paper for more on business services, application services, and platform technology services, and examples thereof.

Processes/scenarios

Processes are step by step behaviors, performed by building blocks, that end in producing a measurable result, delivering a value or meeting a goal.

The frameworks says: “All processes should describe the flow of execution."

And: "A business scenario describes: A business process... the people and computing components (called ‘‘actors’’) who execute the scenario, the desired outcome of proper execution”

More about structural elements

Interface: a collection of services requestable by a client; one way to specify a building block, component or other structural node.

Building block: an active structure, a performer of required activities, which interoperates with other building blocks.

·         Component: a building block definable by one or more services it offers to clients.

·         Function: a logical component that clusters cohesive behaviors by some cohesion criterion other than sequence; a subdivision an organisation’s capability).

 

Structural elements can be related in node connectivity diagrams, communication diagrams or value network diagrams

 

The ArchiMate standard says an interface is a point of access where services are made available.

TOGAF tends to use the terms “interface”, “boundary” and “service portfolio” interchangeably.

(Aside: TOGAF’s “interface catalog” would be better called an information/data flow catalog.)

 

A principle of The Open Group is that clients should invoke services from building blocks via “open” interfaces.

The service-oriented nature of the framework has been a little obscured in version 9, but it still says:

“For each building block, build up a service description portfolio as a set of non-conflicting services.

 

The term building block is sometimes replaced by “component” or some other term.

“A key goal of architecture development is for service modules to be capable of replacement by other modules providing the same service functionality via the same service API.”

Those “service modules” are building blocks that each provide multiple discrete services via an interface.

 

Encapsulation of components behind interfaces is general principle of all business system design, not just software design.

In this Harvard Business Review piece <https://hbr.org/2011/12/first-lets-fire-all-the-managers> Gary Hamel talks about Morning Star.

“Every year, the 23 business units negotiate customer-supplier agreements [interface specifications] with one another.

And each employee negotiates a Colleague Letter of Understanding [an interface specification] with associates most affected by his or her work.

“As a colleague, I agree to provide this report to you, or load these containers into a truck, or operate a piece of equipment in a certain fashion.” [i.e. I agree to provide this collection of services]

This [interface specification] covers as many as 30 activity areas and spells out all the relevant performance metrics.”

Footnote 1: Where some of the principles appear in TOGAF

 

1: Enterprise as a system of interacting building blocks

This basic system theory principle is most obviously evident in:                                                 

·         Chapter 1: Introduction: Executive summary

o   An architecture framework … a method for designing … the enterprise in terms of… building blocks, and… how the building blocks fit together.

·         Chapter 2 Core concepts:

o   Building block: “a component of… capability that can be combined with other building blocks to deliver architectures and solutions.”

o   Architecture: ‘The fundamental organization of a system, embodied in its components, their relationships to each other…”

o   Architecture: “The structure of components, their inter-relationships…”

·         Chapter 6: Preliminary phase

o   “Enterprise architecture … regards the enterprise as a system or system of systems.”

·         Chapter 37: Building Blocks

o   An architecture is a set of building blocks depicted in an architectural model, and a specification of how those building blocks are connected to meet the overall requirements of the business.”

o   Building blocks are encapsulated units of functionality (functions, organisation units, roles, actors, application and technology components).

2: Architecture building blocks abstract from implementation

The separation of logical specifications from physical solutions is evident in Open Group standards from the Unix OS standard onwards.

It is evident in the TOGAF standard, including:

·         TOGAF preface

o   "The Open Group is a vendor-neutral and technology-neutral consortium."

·         Chapter 1: Introduction

o   “Starting from this sound foundation the members of The Open Group Architecture Forum have developed successive versions of TOGAF”

o   The “sound foundation” is the TAFIM principle of logical, service-oriented specification of a system or subsystem.

·         Chapter 2: Core concepts: This clearly separates logical architecture from physical solution.

o   Architecture Building Blocks “describe required capability”

o   Solution Building Blocks are “components… used to implement the required capability”

·         Chapter 39: The Enterprise Continuum: This clearly separates logical architecture from physical solution.

·         Chapter 41: The Architecture Repository: This clearly separates logical architecture from physical solution.

3: The primacy of behavior in building block specification

See below.

6: The generic meta model

This service/process-oriented specification principle is evident throughout the TOGAF standard, including:

Chapter 8: Business architecture: 8.4.1

Chapter 11: Application(s) architecture: 11.4.1.2

Chapter 12: Technology architecture: 12.4.1.2  and 12.4.1

Chapter 22: SOA

Chapter 26: Business scenarios and business goals

Chapter 34: Meta Model

Chapter 37: Building Blocks

Chapter 43: The Technical Reference Model

Footnote 2: a few curious facts

Nothing in the universe is a system until it is named and described as such.
When you look for them, describable systems can be found everywhere, interrelated, nested and overlapping.

 

The dynamics of biological systems are continuous.

By contrast, the dynamics of the business processes we model are discrete, the start and stop, start and stop etc.

We are modelling discrete event driven systems (DEDS).

However, the time interval between events may be small enough to simulate continuous dynamics.

 

We never model individual human actors, we model only the roles they play.

What they do between performing discrete event-driven activities is outside the scope of our system.

 

What UML calls “active objects” are not really active.

Each is a passive structure, composed of state variable values and executable instructions.

The instructions (copied from a class definition) describe how to manipulate the variables.

The truly active structures are the computers that read and perform the instructions held by the objects.

But we never model the computers themselves; instead, we treat the objects as doing the work.

 

 

All free-to-read materials on the http://avancier,web site are paid for out of income from Avancier’s training courses and methods licences.

If you find them helpful, please spread the word and link to the site in whichever social media you use.