TOGAF, CBD and SOA (TOGAF as service-oriented, component-based design)

This page is published under the terms of the licence summarized in the footnote.

All free-to-read materials on 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.


This is one of more than 200 papers on that you might find helpful.

This paper examines the core concepts and entities in the TOGAF meta model with reference to the principles of service-orientation and component-based design.


What is a building block?. 1

Component-based design. 3

Service-oriented specification of components. 3

Defining the behavioural properties of a system.. 5

Reader’s questions. 6


What is a building block?

Read TOGAF Buildings Blocks for in-depth answers to this question.


In short, TOGAF proposes an enterprise’s architecture is described and documented in terms of interoperating building blocks.

A “building block” is a component as in any CBD or SOA methodology that emphasises the specification of active components by interfaces.

This table summarises what TOGAF says about building blocks, which corresponds to what CBD says about components.

TOGAF building block

CBD component

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

is a structural element rather than behavioural.

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

is recursively composable and decomposable.

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

groups behaviours performable by an actor or component instance,

that is, groups services requested of it and/or processes performed by it.

“has a defined boundary”

is encapsulatable behind an interface specification.

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

is related to other components by requesting or delivering services.

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

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.

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


Component-based design

General system theory suggests systems have common features. Typically, in business systems:

·         Components cooperate in processes that create, move and modify objects.

·         Components perform processes in response to discrete events or service requests.

·         Components are bounded by interfaces through which they offer services to other components.


One component can offer more than one service.

One service can be offered by more than one component, though EA discourages duplication of service provision.


How does TOG apply CBD principles?

It defines an enterprise as a collection of inter-related building blocks, each defined by the "service portfolio" it provides.

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


In TOGAF a logical technology component or architecture building block (ABB) defined by the "service portfolio” it is required to provide: e.g. the IETF standard FTP interface.

A physical technology component or solution building block (SBB) is hired, bought or built to realise a logical component’s service portfolio: e.g. the particular FTP server on your device(s).

Read TOGAF Buildings Blocks for more about how components and services are described at different levels of abstraction in TOGAF.

Service-oriented specification of components

The term “service-oriented architecture” (SOA) has been fashionable since the turn of the century, but is used loosely and variously.

People use “service” as a synonym for other kinds of system element (process, component, interface etc.) and for business relationships.

If we are to be unambiguous and systematic about SOA, we have to narrow the meaning of the term.


A fundamental property of a system (as of a component) is its boundary, which separates the system from its environment.

External entities, outside the system of interest, trigger systems (and components in them) to provides services.

All business systems must respond to events that are detected in or received from the wider environment.

So, the concept of the event, and the discrete unit of behaviour it triggers, is essential to business system description.


TOGAF defines a service thus:

an element of behaviour that provides specific functionality in response to requests from actors or other services”

a logical representation of a repeatable business activity, has a specified outcome, is self-contained, is a ‘‘black box’’ to its consumers.”

E.g. Check customer credit, Provide weather report, Consolidate drilling reports.


In other words, a service is a discrete unit of behaviour that encapsulates processing and produces a result for its service requester/consumer.

A service is defined at whatever level of granularity an external entity (playing the role of service requester or consumer) recognises as a discrete operation.

A service encapsulates the processes (aka behaviour, functionality, activities) that respond to an event or meet a service request.


Service documentation

TOGAF builds its “architecture requirement specification” around definitions of required services.

A service contract template (not to be confused with an SLA document) is usually divided into three parts:

·         The signature: the service name, inputs and outputs (from which value may be derived).

·         The functional rules: the preconditions and post conditions of the service.

·         The non-functional rules: including performance and commercial conditions.


Higher level goals and objectives

The detailed requirements for a system can be captured in contracts for the services it provides.

Higher level requirements are the outcomes that provision of those services lead to in the wider environment.

These outcomes, or values, or desired effects, are typically documented as business goals or objectives.


Services as the requirements for systems

The Open Group (TOG) was created with the idea of standardising systems, to enable portability and reuse.

TOG develop and publish vendor and technology-neutral specifications. E.g. the Unix specification.

They achieve this by specifying systems (and components thereof) by the services they offer. For example:


TOGAF 1 to 7 were centred on a Technical Reference Model (TRM).

This defines the enterprise’s complete technology architecture or computing environment by the services it offers (or groups of services).

It defines infrastructure/platform technologies logically, by the services they deliver to business applications.


Service Portfolio

Start, Commit, Roll Back.

Get, Put, Post, Delete.

Print doc, Scan doc

Building Block

Transaction Manager

HTTP Server:



TOGAF 8 and 9 extended this idea into the business and applications domains.

The Architecture Requirements Specification specifies services required of “architecture building blocks” in these domains.





Service Portfolio

Pour drink, Take money.

Register claim, Pay claim.

Building Block

Barman role

Claims application

Defining the behavioural properties of a system

Defining components is not enough; it is necessary to define the services they provide and the processes they cooperate in.

“[Architecture descriptions are] organized in a way that supports reasoning about the structural and behavioral properties of the system and its evolution.”

(ArchiMate® 2.1 Specification, The Open Group.)


A structural view has no start and end points (as in a network diagram, a data model, or a class diagram in UML).

Structural elements describe what a system is made of – are typically called components, actors or roles – and are addressable.

Active components perform processes; passive objects (on which behavior is performed) are not shown here.


A behavioural view has start and end points (as in a flow chart, use case definition, state chart or interaction diagram in UML).

Behavioural elements describe what a system does - are typically called processes or activities – and have a time dimension.

Behavioural elements are usually repeated, and sometimes cyclical.


Service contracts

A service encapsulates behaviours (aka processes, activities) that respond to an event or meet a service request.

Service contract template

·         Signature: service name, inputs and outputs.

·         Functional rules: preconditions and post conditions

·         Non-functional characteristics: including performance and commercial conditions.


A service is defined at whatever level of granularity an external entity (playing the role of service requester or consumer) sees as a discrete operation.


Services are <realised by> Processes

There are human processes, computer processes, and hybrid human-computer processes that may be called workflows or use cases.

A process or activity is

·         specified by defining it to a level of detailed “actions” that actors/components can understand and perform.

·         deployed by publishing it where actors/components can read and perform it

·         performed when actors/components read and follow the published process.

Reader’s questions

Q) What is difference between the Information System and Technology layers?

Application Components (in the IS layer) are business-oriented products that help human Actors by capturing and providing business data.

Technology Components (in the technology layer) are generic products that serve business-oriented Application Components, and each other.

Technology Components include hardware, virtual hardware, operating systems, execution environments, FTP servers, HTTP servers etc.


Both Application Components and Technology Components are technologies, and most are software systems.

The dividing line between them is blurred, especially when it comes to middleware products that move business data around.

Middleware with that is primarily used for message routing are probably best seen as a Technology Component.

Middleware components that apply more sophisticated business rules to data may be seen as Application Components.

If your software system includes building blocks of both types, then it probably ought to be classified as an Application Component.

Or, you can classify it in both layers; it doesn’t matter very much where you position it in the two layers, provided it is related to the right things.

Q) What distinguishes an “Actor” from a “Role”?

One Role can be played by many Actors; one Actor can play many Roles.

The term Actor is used when naming the one individual who plays a particular Role.

But architects never model a human Actor per se; they model only the Roles that Actor play in systems.


An Actor is an individual system component, whereas a Role is a type of component.

Role: a type (e.g. barber, customer, supplier) inside or outside a system.

Actor: an individual (my barber, me, you) who plays a role inside or outside a system.

(Note however that a UML Actor usually = an ArchiMate or TOGAF Role.)


You could reasonably restrict the Role and Actor to human components only.

If the TOGAF meta model had an entity called “electro-mechanical device”, then it would be easier to do this.

Or else, can you add a smiley face to Role and Actor names?

Q) Where is an “Application”?

Application Components are nested. So, an application is an Application Component at the top of a nest of related Application Components.


Consider a bespoke business application that:

·         has client-side and server-side (web server and data server) building blocks.

·         depends on two Web Services (post code look up, date conversion) it shares with other applications.

·         sends messages via a JMS broker to another business application.

·         is subscribed to receive notifications via TIBCO of customer address change events.


Is this one Application Component or many? It depends on the concerns you have to address.

Q) What is an “Information System Service”?

The TOGAF meta model uses the term Process in the business layer only.

But a “use case” is readily seen as a process (with main and alternative paths) encapsulated within an Information System Service.

Q) What are the essential inter-building block relations?

Three generalised building blocks are Service, Logical Component and Physical Component.

The two essential inter-element relations are described below.


Service- Logical Component relation

1 Logical Component <can offer> more than one Service.

1 Service <can be offered by> more than one Logical Component (though ideally only 1).


Physical Component- Logical Component relation

1 Physical Component <can realise> more than one Logical Component.

1 Logical Component <can be realised by> more than one Physical Component (though ideally only 1).

Q) What about “Capability”?

A capability is not a singular architectural entity.

A capability is a view of, or aggregate of, the entities in an enterprise architecture meta model.

Capability = a combination of processes, people and technologies that deliver desired effects.

Capability = a logical encapsulation of those parts of an enterprise or system that deliver required products or services.

A capability can be seen as a required function + aims + activities and resources needed to deliver the effects desired of the named function.


Read Capability-Based Planning in an EA context for more.

Q) Does TOGAF standardise how architects use words in practice?

If only! For a simple example of ambiguity, what does “data architecture” mean?
An IS architect thinks of data at rest (stores) and in motion (flows), the data structures they contain (logical and canonical data models), data qualities, data owners.

An IT architect thinks of disc arrays, NAS, SAN, active/passive, synch/asynchronous replication, availability and disaster recovery.

Different architects use the same words with different meanings.


The terms “service” and interface” are especially ambiguous.

The Web Services Definition Language is an Interface Definition Language that names concepts as shown below.


Behavioural view

Structural view

External view

WS Operation

(service contract)

Web Service

(interface definition)

Internal view


Addresses of components

that perform the operations named in the interface




Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0                     06/05/2016 10:55

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited:” 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