Building blocks and services – more detailed analysis

Copyright 2017 Graham Berrisford. One of about 300 papers at Last updated 29/11/2017 17:10

TOGAF® and ArchiMate® are registered trademarks of The Open Group.


This paper a supplement to a paper you ought to read first.

TOGAF Building Blocks and Services - based on analysis done in 2009 for the British Computer Society.

This paper adds more detail to the first paper above, by way TOGAF methodology and examples.


The essence of the first paper 1

Services in the different domains. 4

The structural view of a system.. 5

A few illustrations. 8

Building blocks in TOGAF’s Architecture Development Method. 9

Building blocks in TOGAF’s Content Framework. 10

Logical and physical building blocks. 13

Notes on the use of ArchiMate symbols. 15

Footnote: more illustrations. 16

Further reading. 18


The essence of the first paper

TOGAF says of enterprise architecture:

·         “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.”


The major deliverables are Architecture Building Blocks and the Architecture Requirements Specification (which contains business and application service contracts).

This division, between structural elements and required behaviors, appears in most system modelling standards (including UML, ArchiMate and TOGAF).

Three principles

Three principles are explicit or implicit in many chapters of TOGAF.

·         Principle 1: An enterprise architecture is composed of interoperating building blocks.

·         Principle 2: An enterprise architecture is an abstract/logical description of building blocks and their interactions.

·         Principle 3: The generic meta model is: required behaviors <are assigned to> logical (architecture) building blocks <are realised by> physical (solution) building blocks.


The appearance and reappearance of these principles is what gives TOGAF coherence and consistency.

The "primacy of behaviour" principle says that the internal structure of a building block is secondary to its behaviors.

The building blocks are required to perform behaviors that deliver services or outputs of value to other building blocks and/or external entities.

Solution building blocks (actors/components of all kinds) are hired, bought or built to realise architecture building blocks, and so perform the required behaviors.


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


So, the TOGAF standard has always been thoroughly service-oriented.

All architecture domains and 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 entities




Cf. other sources?

Required behaviors


Business Services & Processes

IS/Application Services

Platform/Technology Services

Value streams

Logical structures

Architecture Building Blocks

Functions & Roles

Logical Application Components

Logical Technology Components

Capabilities with goals

Physical structures

Solution Building Blocks

Organisation Units & Actors

Physical Application Components

Physical Technology Components

Capabilities with resources

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

Services in the different domains


Services in the business layer

“The TOGAF content framework differentiates between the functions of a business and the services of a business.

Business services are specific functions that have explicit, defined boundaries that are explicitly governed.”

The use of the term functions in the definition of services is confusing – fails to differentiate them.

Business organization units, functions and roles are structural building blocks.

Business services and processes are discrete behaviors that deliver “specified outcomes”.


“Services are distinguished from functions through the explicit definition of a service contract.

A service contract covers the business/functional interface and also the technology/data interface.”

A service may depend on the state of stored business data, and may change that state.

So the functional rules in a service contract may define preconditions and post conditions with reference to business state data.


Services in the applications layer

“The organization’s Application Portfolio is captured as a catalog within the Architecture Repository.

Catalogs are hierarchical in nature and capture a decomposition of a metamodel entity and also decompositions across related model entities

(e.g., logical application component -> physical application component -> information system service).”

This seems a mistake because the meta model says: physical application component <-> logical application component <-> information system service.


The III-RM is a three-layer service-oriented architecture with discrete service requests passing from client apps to service provider apps.

“Information Consumer Applications deliver content to the user of the system, and provide services to request access to information in the system on the user’s behalf

“Brokering Applications manage the requests from any number of clients to and across any number of service providers.

“Information Provider Applications, which provide responses to client requests and rudimentary access to data managed by a particular server.”


Services the technology layer

The Technical Reference Model is the biggest sources of service examples.

It defines both groups of services (sometimes called service portfolios) and individual or discrete services.

E.g. Electronic Mail services include the capability to send, receive, forward, store, display, retrieve...  messages.

Each of those is a discrete event-driven service, which encapsulates a start-to-end process.

Similarly,” Transaction manager services include starting a transaction… committing or rolling back a transaction

(Committing a transaction is process that probably involves thousands of atomic process steps.)

The structural view of a system

This table shows TOGAF and ArchiMate share much by way of core concepts, and use a variety of terms for them.


Behavior elements names

Structure element names

External view

Service, Service Contract

Interface, Boundary, Service Portfolio

Internal view

Process, Value Stream, Scenario

Building Block, Component, Function, Organisation Unit, Role, Actor, Node


The structural view of a system features these terms and concepts.

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 defined by the 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 (cf. a capability).

A node connectivity, communication or value network diagram can relate structure elements of any kind by the exchange of flows or services.


Encapsulation 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.”


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


It is a principle of The Open Group that clients should invoke services via “open” interfaces.

The rationale of TOGAF 1 to 8 has been obscured in TOGAF 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.

Building blocks/components

TOGAF divides the architecture of an enterprise into building blocks - of many shapes and sizes.

Building block varieties include functions, organization units, roles, human actors and application/technology components.

Building blocks interoperate by requesting and providing services.

Building blocks and the services they offer are composed and decomposed.

One large building block may offer scores of discrete services.

On the other hand, a coarse-grained enterprise-level service may require scores of interacting building blocks.


“A good choice of building blocks can lead to improvements in legacy system integration, interoperability, and flexibility in the creation of new systems and applications.” TOGAF.

TOGAF guidance features the declaration of component-based design principles quoted in the table below.

Note that the definitions below apply to business functions/capabilities and roles - as well as application and technology components.


A Building Block in TOGAF 9.1 (quoted from chapter 37)

An Internal Active Structure Element in ArchiMate 3.0 (written here to match)

·         is generally recognizable as "a thing" by domain experts

is a structure element rather than a behavior element.

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

clusters* cohesive behavior elements required by business users (directly or indirectly)

·         has published interfaces to access the functionality. (TOGAF 9 replaced “interfaces” by “boundary”)

exposes behaviors in one or more published interfaces.

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

interoperates with others, which implies client-server or sender-receiver dependencies

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

may be specified with a particular implementation or standard in view.

·         may be assembled from other building blocks.

is recursively composable.

·         may be a subassembly of other building blocks.

is recursively decomposable.

·         is, ideally re-usable and replaceable, and well specified.

should be re-usable and replaceable, and well specified.

·         may have multiple implementations but with different inter-dependent building blocks.

should offer services via interfaces that hide implementation variations.

·         is therefore simply a package of functionality defined to meet business needs.

clusters* cohesive services required by business users (directly or indirectly).

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

is related to others by requesting or delivering services.

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

is encapsulated behind one or more interfaces that are reasonably stable.

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

clusters cohesive services that are cohesive and performable by an instance.


* In general system theory (and TOGAF) terms:

Abstract/logical building blocks (functions, roles, and logical components) cluster behavior types that concrete building blocks can be nominated to perform.

Concrete/physical building blocks (organisation units, actors and physical components) are nominated to realise or perform instances of behavior types.

A few illustrations

The table below illustrates these concepts in accord with TOGAF’s terminology.

General concepts

Required Behaviors

Logical Structures

Candidate Physical Structures

Generic concepts

Architecture Building Block

Solution Building Block

TOGAF elements

Service portfolios

Functions/Capabilities, Roles

Organisation Units, Actors

Business example

Hairdressing service portfolio

·         Wash hair

·         Perm hair

·         Cut hair

·         Manicure


“Curl up and dye”

“Cutters and clippers”


Betty next door

Business example

Marketing service portfolio

·         Research customer requirements

·         Design campaign

·         Promote product or service

·         Analyse customer responses


In-house marketing department

Out-sourced marketing department

TOGAF elements

Service portfolios

Logical Components

Physical Components

Application example

Customer relations service portfolio

·         Gather sales leads from social media

·         Promote product or service

·         Capture order details

·         Close deal

·         Maintain a customer profile

·         Forecast sales

·         Send message to sales or service agent

·         Display dashboard-style analytics

CRM Application





Oracle Siebel


Teamgate CRM


Technology example

The footnote contains technology-specific examples

of service portfolios, logical and physical components

Building blocks in TOGAF’s Architecture Development Method

TOGAF defines systems elements at several levels of abstraction removed from an implemented system.

"building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached."

Architects describe building blocks at several levels of abstraction, depending on what stage of architecture development has been reached.


Phase A: Architecture Vision

Architects gather contextual information (business drivers, principles, goals, visions and plans; system stakeholders and their concerns).

They present, refine and agree this information, getting approval to proceed.

They may name business system components (say Billing, or CRM), with a sketchy description.

"At an early stage, a building block can simply consist of a name or an outline description."


Phases B to D: Architecture Development

Architects proceed to define logical application and technology components, and they services they provide.

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

The description of logical architecture building blocks tends to be generalised, logical and coarse-grained.

Ideally, architects specify architecture building blocks as interface definitions, decoupled from specific solutions. E.g.

·         A Billing function is defined by the 20 business services it provides.

·         A CRM application is defined by the 15 critical use cases it offers via its interface, and 50 business data entities it maintains.

·         An RDBMS is defined by conformance to standards such as SQL, ODBC.


Phases E and F: Planning

Architects identify physical building blocks to realise logical building blocks.

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

They might a select a COTS package, e.g., Oracle DBMS.

Or produce a technology-specific description of a system to built.

These solution building blocks are still abstract descriptions, tending to be coarse-grained, and perhaps still somewhat generalised.

physical elements in an enterprise architecture may still be considerably abstracted from Solution Architecture, design, or implementation views.”

"Later on, a building block may be decomposed into multiple supporting building blocks and may be accompanied by a full specification."

Architects help managers plan the work to implement the physical building blocks


Phases G and H: Implementation and change governance

Remember phase G is not implementation, it is governance of implementation projects carried out in parallel.

in parallel with Phase G, there is the execution of an organizational-specific development process, where the actual development happens.”


Not all building blocks have been defined at the start of phase G.

“In phase G, the specific solution building blocks required [to fill gaps] will be the identified by the solutions architects.”

These solution building blocks are still coarse-grained – they even may be project-sized.

“These solution architecture building blocks may have a one-to-one or many-to-one relationship with the projects.”


Architects monitor the projects that implement new/changed business systems.

“The solutions architects need to define exactly how [reuse of software components] will be done.

There may be other projects working on these same capabilities [here meaning solution building blocks] and the solutions architects need to ensure that they can leverage best value from these investments.”

(For me, TOGAF abuses the term “solution architects”, this is really the level of software architects, but I quote the TOGAF terminology above.)


Architects ensure compliance of deployed systems with architecture building blocks, changing them if need be.

Later, under change management, maintainers maintain concrete elements of the implemented systems.

Architects continue to ensure the compliance of deployed/operational systems with architecture building blocks, changing them if need be.

Building blocks in TOGAF’s Content Framework


Building blocks in TOGAF’s meta model and views

The TOGAF meta model can be tabulated thus:



Required behaviors

are assigned to

Logical structures/building blocks

are realised by

Physical structures/building blocks


Business Services


Organisation Units




IS Services

Logical Application Components

Physical Application Components


Platform Services

Logical Technology Components

Physical Technology Components


Implicit in TOGAF 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.


The generic architectural entities discussed above have different generic qualities.

E.g. behaviors run over time, whereas physical components occupy space and do work.


Common attributes of Behaviors e.g. Services, Processes, Value Streams, Scenarios


“Systems concepts include: system-environment boundary, input, output, process, state….”  (Principia Cybernetica)

The inputs and outputs of a behavior can include materials/goods as well information/data flows.

The preconditions and post conditions of services and processes can refer to system state, as may be recorded in databases.


Common attributes of Logical Building Blocks e.g. Roles, Business Functions/Capabilities, Logical Application and Technology Components

·         name

·         provided interface(s) that group services offered

·         required interface(s) that group services needed

·         behaviors performed

·         physical building blocks that implement the logical building block

·         + generalised requirements for some of the more physical attributes below.


Common attributes of Physical Building Blocks e.g. Actors, Organisation units, Physical Application and Technology Components

·         name

·         deployment place(s) or location(s)

·         abilities possessed: power and memory, or skills and knowledge

·         physical resources used: materials and/or energy

·         cost to employ

·         predicted life span or retirement date

·         logical building blocks realised.


Building blocks in the enterprise continuum

Building blocks are described in artefacts (e.g. an actor/role matrix or business function decomposition) and in deliverables (most notably, an architecture definition document).

TOGAF proposes architects describe building blocks at several levels of abstraction, depending on what stage of architecture development has been reached.

The content framework proposes these specifications are stored in an enterprise repository that is subdivided into requirements, architecture and solutions repositories.

The four rows of the table below map the phases of TOGAF’s architecture development method to these three levels of abstraction, and to operational systems.


  Phase of ADM


Enterprise Continuum

Enterprise  Repository

Notable deliverables




Principles, Vision, and Requirements

Context and requirements

Requirements repository

Drivers and goals

Principles catalogue

Stakeholder communications plan

Architecture requirements specification

Architecture vision

"Architecture Principles, Vision, and Requirements artifacts are intended to

capture the surrounding context of formal architecture models,

including general architecture principles, strategic context that forms input for

architecture modeling, and requirements generated from the architecture."

B, C and D

Architecture building blocks:

e.g. Sales function, CRM, RDBMS.

Architecture continuum

Architecture repository (landscape)

Architecture definition document

“Building blocks are defined in relation to a set of contextual factors."

An Architecture Definition is “a collection of artifacts that document an architecture”.

“The Enterprise Architect has the responsibility for architectural design and documentation

at a landscape and technical reference model level.”

E and F

Solution building blocks

e.g., Oracle DBMS.

Solution continuum

Solution repository

Architecture road map

Implementation and migration plan


G and H

Concrete elements

in deployed solutions.



Operational systems

“This Architecture repository … provides the capability to link architectural assets to

components of the Detailed Design, Deployment, and Service Management Repositories."

Logical and physical building blocks

“[Cybernetics] depends in no essential way on the laws of physics or on the properties of matter.” (Ross Ashby)

A physical component is a material thing that is hired, bought or built to implement/realise specified interfaces (described as “solution building block” in TOGAF).

A logical component is a material-independent component description – often specified in terms of a service portfolio provided (an “architecture building block” in TOGAF).


The Open Group encourages the specification of business systems in an open, vendor-neutral and portable way.

The ADM is an architecture project management method designed to encourage and facilitate EA-level governance.

To this end, it encourages the open, vendor-neutral and portable specifications of solution building blocks.

It specifies them as vendor-neutral architecture building blocks, each defined by a required service portfolio (and/or a logical data model).

It encourages the EA team to maintain this "open" specification in architecture definition documents and an architecture repository.

And it applies this service-oriented principle to business architecture as well as technical architecture.


An aim is to increase agility by reducing impact analysis and EA-level architecture change management time.

And to help the enterprise whenever it wants to, or needs to, migrate from baseline solutions to new solutions.

In procurement, the EA team can evaluate new solutions or products against the current or required architecture building blocks.

If the architecture building blocks are little or not at all affected by a change, then the EA team can readily approve the change.


So, TOGAF divides building blocks between logical specifications and identifiable hireable/buyable/buildable solution building blocks.

Eventually, the solution building blocks are the implemented as physical instances in the run-time or operational system.

Those physical instances could be called "operational building blocks"; however, TOGAF is not designed to address the grey sections of the table below.

It allows the naming of individual human actors and organisation units, but does not expect an architect to identify software classes, objects or component instances.


Structural element types

Structural element instances

Logical architecture building blocks (ABBs)

Physical solution building blocks (SBBs)

Physical instances in deployed systems

(which occupy space and respond when asked to peform behaviors)

A UML class is a logical specification of the behaviors (operations, methods) one or more physical objects can perform.

E.g. A class coded in Java or C#

An object instantiated or deployed in the software system of interest, along with physical resources it needs, so it can respond to requests.

A component is a logical specification of the behaviors (services, uses cases) one or more physical components can perform.

E.g. A named CRM package or DBMS

A component instance deployed in the software system of interest, along with physical resources it needs, so it can respond to requests.

A role is a logical specification of the behaviors (services, duties) one or more physical human actors can perform.

Named actors

A human actor employed or deployed in the business system of interest, along with the rewards and physical resources it needs, so it can respond to requests

A business function is a logical specification of the behaviors (services, processes) one or more physical organisation units can perform.

Named organisation units

An organisation unit instantiated in the business system of interest, along with the budget and physical resources it needs, so it can respond to requests.


A building block is an encapsulated unit of functionality or behavior.

(Or in the case of a data component, it is an encapsulated persistent data structure.)

Architecture building blocks = logical component types = vendor and technology neutral service portfolio specifications.

Solution building blocks = physical component types = vendor or technology-specific specifications of what is hired, bought or built to realise the architecture building blocks.


Note that solution building block documentation does not necessarily specify the building blocks in more detail than architecture building blocks.

TOGAF says specification at the solution building block or physical component level is still "considerably abstracted" from implementation.


Ideally, one architecture building block maps to one solution building block.

Ideally, the architecture building block is a well-defined service portfolio, and a solution building block can be found to deliver it.

Or the architecture building block is a service portfolio reverse-engineered from a known solution building block.

Or the architecture building block is a service portfolio already defined in an “open” interface standard.

In these cases, the solution building block may be little more than a vendor/technology name and version number.


E.g. if the architecture building block is the international FTP interface specification, then the solution building block might be simply "the FTP server embedded in our Unix OS".

So, that particular FTP server component should be replaceable with minimal EA-level impact analysis and architecture change management.


The same principles apply in the human domain.

Given architecture building blocks in the form of a logical function/capability structure, then the solution building blocks might be the units of a corresponding "functional organisation structure".

The EA team does not worry if the management reorganises the organisation structure, providing it can be mapped to the same logical function/capability structure.

Notes on the use of ArchiMate symbols

First, three things to know.

·         ArchiMate's generic meta model is a little flaky and/or misinterpreted.

·         TOGAF is based on a different generic meta model, so no perfect mapping is possible.

·         People use the terms "Building Block" and "Service" to mean anything they fancy.


Note that ArchiMate’s definition of interface appears to embrace two things that may be decoupled.

·         a passive interface specification (e.g. a restaurant menu)

·         an internal active structure element via which services can be accessed (e.g. a waiter).

The latter might better be modelled as a business role or function rather than a business interface.

Note also that an ArchiMate interface is bound to one and only one internal active structure element, which prevents the decoupling of interfaces from components/roles.


TOGAF recommends defining an Architecture BB by its service portfolio (a potential interface).

The general relationship is that Solution BBs <realise> Architecture BBs.

Which is to say physical components <realise> logical components.


If your Architecture BB defines an Interface, then you can use the Interface symbol.

Else use the Function symbol (a logical component that ArchiMate misplaces alongside Process.)

Using the Function symbol avoids the constraint in ArchiMate that Interface acts as a façade Component to 1 and only 1 server Component.


You may use the Component symbol (since Function is a specialisation of Component).

But do not use the Service symbol, which is a contract for a discrete, unitary, behavior in TOGAF.

(Surely also in ArchiMate, though example diagrams confuse Service with Interface or Component.)


Remember, in TOGAF, Solution BBs <realise> Architecture BBs.

The relationship is realisation rather than other plausible candidates like specialisation or assignment.
(Specialisation is left to right in TOGAF’s Enterprise Continuum, not top to bottom.)

(Assignment in ArchiMate is primarily for assignment of structural elements to behavioral elements.)

ArchiMate rules won’t let you connect Interface to Component by realisation or specialisation.

Which is another reason to use the Function symbol for the Architecture BB.

Footnote: more illustrations

This table contains technology-specific examples of service portfolios, logical and physical components.

General concepts

Required Behaviors

Logical Structures

Candidate Physical Structures

Generic concepts

Architecture Building Block

Solution Building Block

TOGAF elements

Service portfolios

Logical Components

Physical Components


Technology example

Operating System service portfolio

as defined in The Open Group’s Unix standard.


BSD (variations)



Linux. Android. Chrome OS.



Plan 9

QNX. BlackBerry 10.


Technology example

App server service portfolio

·         Administration

·         Caching (perhaps distributed)

·         Clustering

·         Compression

·         Deployment API (perhaps distributed)

·         Failover

·         Security

·         SSL

·         Transactions

·         URL rewriting

·         Virtual Hosts

·         Web Services standards

·         Java Authentication and Authorization Service (JAAS)

·         Java EE

·         Java Management Extensions,

·         Java Message Service (JMS)

·         Java Naming and Directory Interface (JNDI)

·         Java Persistence API (JPA)

·         Java Remote Method Invocation (RMI)

·         Java Server Faces (JSF)

·         Java Server Pages (JSP)

·         Java Transaction API (JTA)

Application Server

Glassfish (Oracle)

JBoss Enterprise Application Platform


Apache Tomcat

Apache TomEE

Apache Geronimo



Resin Servlet Container (Open Source)



Technology example

Messaging service portfolio (see table below this one)

·         Route messages

·         Convert between protocols

·         Convert between data types

·         Validate data against schema

·         Invoke services

·         Orchestrate services

·         Split and merge messages

·         Managed messages

·         Manage transaction

·         Encrypt data

·         Secure messages

Enterprise Services Bus


Apache Service Mix

Mule ESB

Spring Integration



Petals ESB


This table says more about messaging service categories.

Messaging service categories

Route messages

static routing, content-based routing, rules-based routing, policy-based routing

Convert between protocols

conversion between standard communication protocols

Convert between data types

conversion between data types, formats and values

Validate data against schema

validation of data items against types in predefined data schemas or canonical data models

Invoke services

synchronous and asynchronous invocation, service mapping (locating and binding), reliable delivery

Orchestrate services

coordination of invocations within a single aggregate service

Split and merge messages

splitting and combining messages and handling exceptions

Managed messages

monitoring, auditing, logging, metering of messages (perhaps reported on a console)

Manage transactions

starting, committing and rolling back of transactions

Encrypt data

encryption and signing of messages

Secure messages

identification, authentication and authorization of ESB use

Further reading

References to TOGAF refer to version 9 or 9.1 unless otherwise stated.

This is a supplement to three related papers you might read.


·         The TOGAF standard Building Blocks and Services - based on analysis done in 2009 for the British Computer Society.

·         The TOGAF standard mapped to “Capabilities” in the NATO Architecture Framework

·         The TOGAF standard mapped to “Capabilities” in Business Architecture


Read also TOGAF, CBD and SOA for more on the principles of service-oriented component specification in TOGAF.



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.