The confusing entanglement of architecture dimensions

One of more than 200 papers at  Copyright Graham Berrisford.  Last updated  02/07/2016 15:41


This is one of several related papers, including:

1.      The system theory underpinning TOGAF and ArchiMate

2.      Business functions and processes in TOGAF

3.      Building blocks and services (also value streams and chains) in TOGAF

4.      Business function and capabilities in TOGAF and VDML

5.      The confusing entanglement of architecture dimensions

6.      TOGAF and ArchiMate harmonisation.


References are to TOGAF 9.1, ArchiMate 2.1, UML 2.4.1 and VDML 1.0.


Preface. 1

The relationships between components, interfaces and services. 2

The structure/behavior dimension (1) 3

The external/internal dimension (2) 6

The type/instance dimension (3) 7

The logical/physical dimension (4) 9

Entanglement of dimensions in practical methodologies. 10

Footnotes. 12

Footnote 1: On type and instance. 12

Footnote 2: The difference between “Proper Domain Models and "Concept Graphs”. 12



Business system architects design human activity systems using models that conform to the usual presumptions about designed systems.

For example, the models describe systems in terms of structural and behavioral elements.

Behaviours run over time from start to end, or cyclically (one might add that structures occupy space).

This table draws a distinction between structural and behavioral views of a system (cf. UML p 694).

A dynamic or

behavioral view

of a system

Shows the behavior (of a role or interacting roles) over time

Shows actions, interactions or life histories of actors playing roles.

Describes behavior as a series of changes over time.

A static or

structural view

of a system

Shows the structure of a system irrespective of time.

Shows relationships between roles.

Does not detail behavior but may relate named behaviors to roles.


Systems are commonly described in terms of roles, events and behaviors

It sometimes helps to use a different label for instances of those elements (in a run-time system) as this table indicates.

System elements

System description

Model types

Operational system

Real world instances

Structural elements



Behavioral elements






Architecture frameworks and modelling languages are used to describe and design business systems.

These systems are specifiable at many levels of abstraction from high-level views down to the bottom level of atomic actions that individual actors can be asked to perform.

And they can be specified from different viewpoints, as this table illustrates.

Activity system

Behavioral view

Structural view

External view



Internal view




A system’s interface encapsulates actors (humans and mechanical components); these structural elements must be addressable.

External events or service requests prompt the internal actors to perform actions (operations or processes); these behavioral elements run over time.

The four-view table above is attractively simple, but open to interpretation and debate, and it can be confusing.

This paper discusses four dimensions of architecture description; each can be confusing in its own right, and worse, they are entangled with each other.

The relationships between components, interfaces and services

TOGAF divides the architecture of an enterprise into actors.

The actors are called building blocks (perhaps because they encompass human actors and technology components).

Each building block can perform one or more behaviors, on its own or in cooperation with other building blocks.

Building blocks come in several shapes and sizes: functions, roles, organization units, human actors and application/technology components.

Building blocks are defined in the manner of components that interoperate by requesting and providing services.


Each building block is definable by the service portfolio (an aggregate of discrete, singular, services) it offers to others.

A service is a repeatable activity that (if successful) ends in a desired outcome.

A service ends with a result/output/product of value to the service requester or receiver.

A service is a logical contract that encapsulates whatever process(es) are need to deliver the value required.


ArchiMate’s definitions appear to say an interface offers one service.

“A business interface exposes the functionality of a business service to other business roles”

“An application interface exposes an application service to the environment.”.


But read on, and you’ll find one interface can aggregate many services.

 “A business interface may be assigned to one or more business services, which means that these services are exposed by the interface.”

 “An application interface is the (logical) channel through which the services of a component can be accessed.”

Further: “The same application service may be exposed through different interfaces.” Ah, N-to-N then!


TOGAF and ArchiMate both define a service as a discrete unit of behavior

Both presume one component can offer many services through an interface.

And many examples out there do conform to those definitions.

Why not all? Perhaps because UML and others use the word service as a synonym for interface, and operation for service.


To edit paraphrase what UML says in sections 7.3.24 & 25.

“An interface is a kind of component type that represents a declaration of a set of coherent public features and obligations.

An interface specifies a contract; any instance of a component that realizes the interface must fulfill that contract.

Since interfaces are specifications, they are not instantiable, and are implemented by instance of instantiable component types.

Note that a given component may implement more than one interface and that an interface may be implemented by a number of different components.”

The set of interfaces implemented by the component are its provided interfaces and signify the set of services the component offers to its clients.

The component will have an implementation for each of operations defined by the interface.”


The term service is now widely used to label anything and everything - an interface, a process, an application component, a“system software” node.

People draw a message broker box associated 1-to-1 with a “messaging service” box, which is to say nothing of architectural significance

They speak of one address component offering one “address service”, when they really mean the component offers a service portfolio..

They even speak of components as services (e.g. speak of small applications as micro services).


In natural language, people use same word for a singular behavior and an aggregate structure of behaviors.

The term “process” is used to mean a single procedure or a whole application (in Windows Task Manager).

And the term “service” is used mean one discrete operation, or a multi-service portfolio.


Natural language is not controlled enough for people wanting to describe things unambiguously.

A professional modeller does not use the same word for many concepts, or several words for one concept.

And a professional modelling language discourages people from using graphical symbols a loosely as words.

The structure/behavior dimension (1)

System theory draws a distinction between structural and behavioral views of a system (as does UML p 694).

A dynamic or behavioral view of a system shows a behavior (of a role or interacting roles) over time; the actions and interactions within a behavior run from start to end.

A static or structural view shows a system’s structure irrespective of time; it shows relationships between roles, and may relate named behaviors to roles.


Why do people sometimes struggle with the structure/behavior distinction?

Because behaviors have structures; and structures have behaviors.

A process is a structure of actions in a time sequence, yet is called a behavior here.

A role defines behaviors actors can be asked to perform, yet is called a structure here.


How people use words in natural language is very loose.

Natural language can obscure the controlled language our profession needs to define the dimensions of architecture.

A controlled vocabulary has to pin the meanings of terms (like structure and behavior) to even more general concepts.


Structures in space versus behaviors over time

In short: actors occupy space; actions take time.

UML divides its views of a system between structure and behavior diagrams.

UML structure diagrams show element types (classes, roles, components) whose instances are addressable, implying they occupy a position in space.

All actors, all active components (and all passive structures/data elements) must be locatable in space.


UML behavior diagrams show element types (use cases, interactions, etc) whose instances run from start to end over time.

All actions (performed by actors, acting on passive structures/data) are triggered by events and run from start to end over time.


Structural and behavioral aggregation

An aggregate structure takes up more space than any of the smaller structures aggregated into the structure.

Given that a human actor or software component occupies space, a coarser-grained aggregation of actors or components needs more space.

An aggregate behavior lasts longer than any of the shorter behaviors aggregated into the behavior.

Given that a process performance occupies time; a coarse-grained process must last longer than each of its process steps.


But note, there are two kinds of behavior aggregation – behavioral and structural.

Connecting process steps in sequence creates a longer behavior element.

Grouping process steps by some other cohesion criterion and assigning them to a role or function creates a structure element.


Q) Are you just pointing out that these terms are used in multiple ways?

A) More than that; I am saying ArchiMate has a peculiar view of the structure/behavior distinction.


The names of structures and behaviors

ArchiMate says: “These three aspects – active structure, behavior, and passive structure – have been inspired by natural language,

where a sentence has a subject (active structure), a verb (behavior), and an object (passive structure).”


Natural language is loose; nouns and verbs are imperfect indicators of a structure/behavior distinction.

And you can’t rely on a thing’s name to tell you whether it is structural or behavioral.


The term “function” is especially ambiguous.

Functionality = behavior in the broad sense. Functioning = active in the run-time sense. So what is a “function”?

In natural language, the function of a thing often means its purpose.

In UML, a function is a behavior; runs over time from receiving input to producing output, but without access to system state.

In TOGAF, a function is a structure, a node in a logical functional/capability decomposition structure; it does not run over time.

It can be defined as an aggregate of related business actions (internal view) or portfolio of services offered (external view).


The logic behind the system elements you find in UML, ArchiMate and TOGAF

A start-to-end behavior has a structure. An active structure can be seen as an aggregate of performable behaviors. Confusing?

Understanding the behavior/structure distinction helps in understanding TOGAF, even if the authors are not conscious of the logic behind what they write (e.g. page 333 and chapter 37).


A behavior element (a service or process) flows over time from start to end, and terminates by delivering a result of value.

TOGAF assumes behaviors are performed by interoperating “building blocks” in response to triggering events, messages or invocations.


Structural elements can be divided between logical types which aggregate behavior specifications, and physical instances which actually perform those behaviors.

TOGAF calls these building blocks (BBs) and further divides the types between logical ABBs and identifiable hireable/buyable/buildable SBBs.


The 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 is instantiated or deployed in the software system of interest, along with physical resources it needs, so it can respond to requests.

A component interface 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 is deployed in the software system of interest, along with physical resources it needs, so it can respond to requests.

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

Named actors

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

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 is instantiated in the business system of interest, along with the budget and physical resources it needs, so it can respond to requests.


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

ArchiMate curiously classifies functions alongside processes, as though functions are event-triggered behaviors.

ArchiMate has some peculiarities that make alignment with TOGAF difficult. For further analysis, see footnote 1.

The external/internal dimension (2)

A system is a bounded collection of actors performing actions; it is separated from its external environment by an interface.


Consider the holding of board meetings as a system.

An invitation list defines a group of actors - a structure of actors in different roles, who follow the agenda and interact in the board room.

A meeting agenda defines a time-bound sequence of actions - a behavior in which actors playing different roles interact.

Inside the boardroom, the actors study inputs, interact, reach conclusions and define goals and actions

Those outside see only inputs (briefs they may help to prepare) and outputs (goals and actions) they must respond to.  


Why do people find the external/internal distinction confusing?

Because systems are composed and decomposed, formally and informally.

So, what is external to a smaller system/component can be internal to a bigger system/component.

Still, at every level of granularity, the external view is a specification of behaviors that encapsulates internal actors/components that perform behaviors.


Arguably, roles and functions are more like external interface/type definitions than they are like internal actors and components.

E.g. TOGAF aggregates required service types into service portfolios.

Each portfolio is specification of behaviors that actors or components inside the system are expected to perform.


Behavioral view

Structural view

External view


Service portfolios

Internal view


Actors, Organization Units & Components


Service portfolios are assigned to logical roles, functions and components (this is a business principle as much as software principle.)

The TOGAF view is perhaps better expressed as in the table below.


Behavioral view

Structural view

External view


Logical Roles, Functions & Components

Internal view


Physical Actors, Organization Units & Components


ArchiMate classifies elements differently; it positions functions as internal behaviors alongside processes.


Behavioral view

Structural view

External view



Internal view

Processes & Functions

Actors, Roles & Components


ArchiMate says: “A business process is defined as a behavior element that groups behavior based on an ordering of actions.”

As you’d expect, the actions in a process are ordered in a time sequence; this differentiates a process from a function.


WSDL is an interface definition language, but confusingly calls an interface a web service.

Each web service is a service portfolio, an aggregate of discretely-requestable services that WSDL calls operations.

A web service holds the addresses of component instances that realize the operations.


Behavioral view

Structural view

External view

WS Operations

Web Services

Internal view

Component instances addressed


Another source of confusion is that the external/internal distinction is relatable to either or both of the next two distinctions.

The type/instance dimension (3)

An instance is a particular thing that realizes or embodies the properties in a type (found in a description or model).

Why do people find this distinction confusing? Because it is! It is very hard to get your head around it.


Board meeting is a type: it describes instances of which there may be many; it describes properties they all share.

A board meeting is an instance: it is an occurrence of the type; it has many unique properties not described in the general type.


“The ArchiMate language intentionally does not support a difference between types and instances.”


Except that does!

In ArchiMate, the actor symbol represents what might be called a singleton type, which can be identified using an individual instance name.

You can label the actor symbol with a role/type name (say CEO) and/or an actor/instance identity (say CEO Joe Soap).


The types in the meta models of modelling languages are generic system description types (such as role and process).

The types in user models (such as student and application) may be seen either as specializations of the more generic types, or as instances of their use.

Run-time instances are things (such as individual students and applications-in-progress) that embody types in operational systems.


The table below is a translation of ArchiMate Figure 1.


Model at different levels



A general theory

ArchiMate's generic meta model

Generic entity types

Behavior element

Active structure element


Enterprise architecture

ArchiMate's meta model

Specializations or instances of level 1 types

Business process

Business role or actor


Domain-specific models

ArchiMate user's model

Specializations or instances of level 2 types

Sale process

Marketing director


Operational systems

ArchiMate user's business systems

Instantiation of level 3 types

Particular sales

Henry Miller


The equivalent in TOGAF could be this.


Models at different levels



EA principles

TOGAF's generic meta model

Generic entity types


Logical component

Physical component


Enterprise architecture

TOGAF's meta model

Specializations or instances of level 1 types

Business service


Organization unit


Business-specific models

TOGAF user's model

Specializations or instances of level 2 types

Brokered sale


Sales department


Operational systems

TOGAF user's business systems

Instantiation of level 3 types

Particular sales

Sales people


TOGAF distinguishes roles from individual actors, and business functions from individual organization units.


Behavioral view

Structural view



Roles & Functions



Actors & Organization Units


In TOGAF: requirements <specify> service portfolios <are assigned to> logical architecture building blocks.

Logical architecture building blocks <are specialized or realized by> physical solution building blocks <which are realized or instantiated by> deployed solutions.




Required behavior to built structure

Types to instances



Required Services & Scenarios

Behavioral types


Logical building blocks

More required Services & Processes

Roles, Functions & Logical Components (service portfolios)

Behavioral types

Structural types (aggregate behaviors)


Physical building blocks

Actors, Organization Units & Physical Components

Specializations of structural types

Instance names


Deployed solutions

Instances of types


Curiously (see footnote 1 for more)

Instances of structure elements are usually called physical, and are sometimes named in models.

Instances of behavior elements are usually called logical, and are well-nigh never named in models.


The UML standard takes care to distinguish types from instances using different words.

Yet it still manages to blur structural types and instances by equating actor with role.


ArchiMate doesn’t officially draw a type/instance distinction.

Nevertheless, at least some of the types in a system description must be instantiated as actors in an operational system.

And some ArchiMate sentences mean different things depending on whether the words apply to types or instances.

The logical/physical dimension (4)

Why do people find the logical/physical distinction confusing? Because there are countless interpretations of it.

A classic four-level idealisation hierarchy is: conceptual <abstracts from> logical <abstracts from> physical <abstracts from> real.

The terms conceptual, logical and physical are often used to label three increasingly elaborate specifications of things to be deployed.

But there are many different interpretations of what each level means and is used for.

In network engineering, logical/physical means software/hardware.

In database design, logical/physical means normalised for integrity/structured for performance.

Enterprise data architects have their own domain-specific interpretations.


Here is a reasonably conventional way of distinguishing conceptual, logical and physical, much as in TOGAF.

Idealisation hierarchy


Conceptual model

Specifies business processes and/or data in a computing-independent way.

It need not be related to any particular computer, application or database, but may be reversed engineered from or related to them.

Logical components

Abstract roles, functions, application and technology components (envisaged or observed).

Components are encapsulated and defined by a service portfolio (and sometimes a data model) along with non-functional requirements.

They are not explicitly related to any vendor or technology product choice, but may be reversed engineered from or related to specific products

Physical components

What is hired, bought or built to realize the logical specification; may be vendor or technology-specific.

Named actors, organization units, data/application/technology component types and instances.

Their specifications include actual non-functional attributes, costs, configuration and deployment requirements.

Deployed solutions

The actors and components of the operational system, configured and deployed to perform actions as specified above.


In TOGAF (and in TOG more widely) logical primarily means vendor/technology neutral specification of components by service portfolios.

Logical roles are realized by physical actors; logical components are realized by more physical components.

A logical business function/capability decomposition structure is realized by a physical organization structure.

A “functional organization structure” is an organization structure that matches a logical functional/capability decomposition.

You might think of a business capability as a purely logical function, or as the one or more organization units that realize the function.


ArchiMate doesn’t explicitly draw a logical/physical distinction.

Likely because it does draw behavior/structure and external/internal distinctions, both of which can be interpreted as logical/physical.

And it (sadly) ducks drawing a type/instance distinction, which is also interpretable as logical/physical.

Entanglement of dimensions in practical methodologies

TOGAF is centered on dividing a system into components (structures) defined by the services (behaviors) they provide.

It doesn’t feature the term “interface”, but does specify logical building blocks by defining their "service portfolios”.

Outside of the business domain, TOGAF does not expect architects to detail internal processes.

Its core architecture description elements can be classified using three dimensions as shown below.





Business Services

IS Services

Platform Services

(Service Portfolios)


Business Processes

Business Functions, Roles

Logical Application Components

Logical Technology Components

Logical Building Blocks

Organisation Units, Actors

Physical Application Components

Physical Technology Components

Physical Building Blocks


ArchiMate elements can be classified in a similar way; read “TOGAF and ArchiMate harmonisation” for more.


TOGAF starts with analysis of the business/human context, so there is a business to technology sequence (left to right below).

In each architecture domain, it starts by defining required services in the requirements specification.

It then proceeds by defining structural building blocks, first at logical level and then at a physical level (top to bottom below).

This table arranges these two sequences in a way that that shows correspondences between concepts in different architecture domains.

TOGAF level

Business domain

Information systems domain

Technology domain


Event, Business Service, Product

Info/Data Entity

Appl/IS Service

Technology Service

Logical building  blocks etc.

Function, Role, Process

Log Info Component

Log App Component

Log Tech Component

Physical building  blocks

Organization Unit, actor        

Phys Info Component

Phys App Component

Phys Tech Component


The business to technology sequence is one of several sequential threads; others include baseline to target and generic to specific.

This paper suggests sequences from 1) required behavior to built structure, 2) external to internal, 3) types to instances and 4) logical to physical.

TOGAF’s architecture development method can be seen as interweaving all these sequences.

The table below squashes several dimensions into a two-dimensional table, but the dimensions cannot be perfectly aligned.





to internal

Required behavior to built structure

Types to instances


to physical



Required Services & Scenarios

External view

Behavioral types



Logical building blocks

More required Services & Processes

Roles, Functions & Logical Components (service portfolios)

External view

Internal view

Behavioral types

Structural types (aggregate behaviors)




Physical building blocks

Actors, Organization Units & Physical Components

Internal view

Specializations of structural types

Instance names



Deployed solutions

Instances of types



It doesn’t seem right to say required services and scenarios are conceptual, since they have physical qualities and may deliver physical products.

The logical/physical distinction drawn in TOGAF is mostly intended to encourage vendor-neutral specification of business and IT systems.



This is one of more than 200 papers at


Footnote 1: On type and instance

This footnote grew so large, and so dominated by questions about ArchiMate, it has been removed from here into a paper in on its own.

“Things the next ArchiMate standard might address”.

Most notably, this paper expands on the discussion of types and instances.

It also explains discrepancies between ArchiMate’s graphical meta models and its Relationship Table appendix.

And why it is meaningless to think of a collaboration as an instance, but OK to think of it as an N-way association relationship.

Footnote 2: The difference between “Proper Domain Models and "Concept Graphs”

Domain models (including those in international standards and books) are often drawn using UML class diagram notations.
Those class diagrams often feature class hierarchies, and show association cardinalities that imply questionable 1-1 associations.

But in human affairs (rather than in mathematics) the passage of time undermines class hierarchies

And cardinality constraints on relationships need to account for the full life span of persistent entity instances.


Software designers often model objects that live only a short time in memory (perhaps reflecting data in a small view of a larger database).

Their code may be built around an aggregate entity (say an on-line shopping basket) that lives for only seconds or minutes.

They may be careless about the specifying the cardinality on association relationships, because it has no impact on their implemented software.


The passage of time undermines class hierarchies in models of persistent business entities.

E.g. you may start out by classifying every person as either a man or a woman.

But over time, sex changes turn these “types” into “states” of a person.

Within a system generation - one object may change from one type to another.

Between system generations - a type/class hierarchy is often revised – implying persistent entities must be re-classified.

The result is that specialization relationships are less common in models of long-lived entities in business domain models.


To specify the cardinality of associations requires some life history analysis.

Associations between types in a model at level N should be labelled to specify how instances at level N+1 are related.

The rules constraining association relationships between entity types in model apply to instances of those entities.

Business database designers understand this well, because it has an impact on the birth and death of persistent entities.

E.g. a mandatory 1-N association between entity types A and B implies start-of-life constraint on the existence of instances of type B (A must exist).

It may also imply an end-of-life constraint on instances of type A (all Bs must have died already).


Other modellers think of object instances at a moment in time, they don’t think how time turns 1-to-1 associations into 1 to N, or N-to-N.
They aren’t taught how to analyse association cardinalities, and don’t worry about them.

They may not even realize cardinalities apply to objects/instances rather than classes/types.

So they are careless in drawing domain models; they

·         draw composites in place of aggregates, and aggregates in place of associations

·         draw 1-to-1 associations in place of 1-to-N, and 1-to-N in place of N-to-N

·         draw an N-to-N association that hides a link entity important to the domain.

·         draw one association relationship between two entities where there are two or more different associations

·         completely omit some important associations.

The trouble is that the resulting domain model is not a true reflection of the real-world business domain.

Safer, call it a cartoon, or an informal "concept graph", and leave the cardinality of associations unspecified.