The TOGAF standard’s building blocks and services

Copyright 2017 Graham Berrisford. One of about 300 papers at Last updated 12/10/2017 01:02

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


This is one of several popular papers on the TOGAF standard that are posted on the home page

In this paper, the standard is sometimes called “the framework”.

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

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

This is the first of two related papers - based on analysis done in 2009 for the British Computer Society.


Service-oriented architecture development 1

More about building blocks in the framework. 3

More about behavioral elements in the framework. 5

More about structural elements in the framework. 6

Aligning standards. 7

More detail on building blocks and services. 8


Service-oriented architecture development

Unlike traditional building architects, the systems we architect are activity systems - usually human and computer activity systems.

These systems are designed to perform behaviors that deliver outputs that serve the needs of external entities in the wider environment.

The "primacy of behaviour" principle says the structure is secondary; the internal structure can change without changing the system's use or value.

Structural actors/components/building blocks are only hired, bought or built to perform required behaviors.


The UML standard sets out the two premises that underpin all business system modelling:

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

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


The TOGAF standard has always been thoroughly service-oriented.

It regards an enterprise as a system, that is, a collection of encapsulated building blocks that interact in regular behaviors.

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

The table below shows the terms used when abstracting services from building blocks.

Generic meta model

Generic entities




Required behaviors


Business Services

IS/Application Services

Platform/Technology Services


Building Blocks

Functions & Roles

Application Components

Technology Components

Building blocks

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

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

A building block in the TOGAF standard

A component in general terms

“is generally recognizable as "a thing" by domain experts”

A component is a structural element rather than behavioral.

“may be assembled from other building blocks; may be a subassembly of other building blocks”

It is recursively composable and decomposable.

“is a package of functionality defined to meet the business needs across an organization.”

It clusters cohesive behaviors performable by an actor or component instance,

It clusters cohesive services requested of it and/or processes performed by it.

“has a defined boundary”

It is encapsulatable behind an interface specification.

“may interoperate with other, inter-dependent, building blocks.”

It is related to other components by requesting or delivering services.

“Ideally, is re-usable and replaceable, and well specified.”

It should offer generally useful services via an interface that is free of implementation detail.

“considers implementation and usage, and evolves to exploit technology and standards.

It can be specified with particular technology-specific components in mind, or reverse-engineered from them.


This second table quotes definitions of service in two 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.


The overall coherence and consistency of the framework’s content framework depends on three general principles:

1.      An enterprise is composed of interoperating building blocks (components, functions, organisation units, roles, actors, nodes).

2.      An enterprise architecture is an abstract (conceptual, logical) description of building blocks, their interactions and the services they offer.

3.      The generic meta model is this: required behaviors <are assigned to> logical structures <are realised by> physical structures.


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).


So, the 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.

More about building blocks in the framework

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.


The framework 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.”


The framework 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)


Positioning building blocks in a three-dimensional classification of system elements

A dynamic or behavioral view of a system shows a service or process that runs from start to end over time.

A static or structural view shows a structure of building blocks irrespective of time.

The framework specifies an internal building block by defining its external boundary, service portfolio or interface.

The framework abstracts logical or vendor-neutral architecture building blocks from physical solution building blocks.


The framework’s core meta model/architecture entities can be classified using these ideas as in the table below.




Level of abstraction


Business Services

IS Services

Platform Services

Service Portfolios, Boundaries

Required behaviors


Business Processes

Business Functions, Roles

Logical Application Components

Logical Technology Components

Logical / Architecture

Building Blocks

Organisation Units, Actors

Physical Application Components

Physical Technology Components

Physical / Solution

Building Blocks

More about behavioral elements in the framework

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.


“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 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 in the framework

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.

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

(Aside: “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 <> 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.”

Aligning standards

To align the vocabularies of different standards we simply cannot tackle terms one by one.

We have to step back., because some terms are generalisation or specialisations of other terms

Also, there are flaws/niggles in the generic meta models of different standards - and they don't match perfectly.


Underpinning all standards are the wider generalisations general system theory.

We have to distinguish where different terms are being used to distinguish:

·         different system theory concepts (notably structures/components and behaviors/services)

·         different levels of granularity in one concept (as in functional decomposition or process decomposition)

·         different specialisations of one generic concept in different architecture layers (e.g. human actors and computer actors).



The core of the explicit generic meta model can be tabulated thus


Behavior elements names

Structure element names

External view



Internal view


Role, Actor, Component, Node



The core of the meta model can be distilled and tabulated thus:


Required behaviors

Logical structures/building blocks

Physical structures/building blocks


Business Services


Organisation Units



Information Systems

IS Services

Logical Application Components

Physical Application Components


Platform Services

Logical Technology Components

Physical Technology Components


Implicit are the equations: function = logical business component, and organisation unit = physical business component.

The abstract/logical building blocks cluster behavior types that concrete building blocks can be nominated to perform.

The concrete/physical building blocks are nominated to realise or perform instances of those behavior types.


ArchiMate mapped to TOGAF

The ArchiMate standard does not distinguish logical structures from physical structures

Still, the meta model can be tabulated for comparison with TOGAF thus.


Required behaviors

Logical structures

Physical structures

Business layer

Business Services




Application layer

Application Services

Application Interfaces & Functions

Application Components

Technology layer

Platform Services

Technology Interfaces & Functions



For more on alignment of the framework and the Modelling, read this paper on their alignment.

More detail on building blocks and services

This is the first of two related papers, you can find more detail in the second paper below.

1.      Building blocks and services – introduction – based on analysis done in 2009 for the British Computer Society

2.      Building blocks and services - detail  - adds methodology and examples to the introductory paper.

Footnote: the grand illusion!

The UML standard sets out the two premises that underpin all business system modelling:

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

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


The dynamics of biological systems are continuous.

Their processes cannot be stopped, which is a defining feature of life in general.

By contrast, the processes of the designed business systems we model start and stop.

Because the dynamics of these systems are discrete event driven (they are DEDS).


There is a grand illusion in our models

What UML calls active (software) objects are not really active.

Each is a passive structure:

·         A set of state variable values

·         A set of instructions (activities copied from a class definition) for manipulating those variables.

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

But we never model computers.


And since the business systems we model are discrete event driven it could be argued that...

The active (human) actors in a business system are not really active.

Each is a passive structure:

·         A body/memory structure

·         A set of instructions (activities copied from a role definition) to be followed.

The truly active structures are the biological organisms that read and perform those instructions.

But we never model continuously dynamic organisms.

In fact, we never model people, we only model the roles they play in discrete event-driven activities.



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.