Premise 3: Structures are space bound

How to align ArchiMate with UML and TOGAF

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

This is one in a series of papers that present premises and principles for using business system modelling languages and frameworks in a way that is compatible with system theory.

Principles

Introduction. 1

Principle 3a: A behavioral element type describes (each member in a set of) similar start-to-end (or cyclical) performances 1

Principle 3b: Roles and functions identify rather than perform behaviours. 1

Principle 3c: Clustering discrete services makes a structural function, not a larger service. 2

Principle 3d: One-to-one relationships and synonym boxes can be redundant 3

Introduction

Premise: All behaviours in a system are performed by actors or components that occupy space and must be addressable.

Interfaces, roles and functions do not perform behaviour, they only identify behaviours. They name behaviours that addressable components, human actors and organization unit actors are responsible for.

Principle 3a: A behavioral element type describes (each member in a set of) similar start-to-end (or cyclical) performances

ArchiMate’s processes are start-to-end or cyclical, but its functions are not. Since functions are more like roles, classifying them as behavioral is confusing. ArchiMate tries to draw a distinction by saying roles represent responsibilities for behaviour, whereas functions describe that behaviour, but the following discussion suggests this is sophistry.

Principle 3b: Roles and functions identify rather than perform behaviours

What makes a thing (subject or object) structural? That it is addressable. If you can't locate a subject in space, you can't ask it to do work. If you can't locate an object in space, you can't work on it. Further, what makes a structural element active? That it performs one or more behaviours (each of which has a purely logical structure over time), or identifies or names behaviours to be performed.

Components, organisation units and actors perform behaviours. Interfaces, roles and functions do not; they only identify/name behaviours.

· Separating interfaces (which name behaviours) from components (responsible for performing behaviours) separates what is to be done from how it is assigned to components in a system structure.

· Separating functions (which name behaviours) from organization units (responsible for performing behaviours) separates what is to be done from how it is assigned to organisation units.

· Separating roles (which name behaviours) from actors (responsible for performing behaviours) separates what is to be done from how it is assigned to human beings.

Note that ArchiMate uses the term actor for both an individual organisation unit and for an individual person.

What a system can do is identified in definitions of its active structural elements. Business functions identify what organisation units do, and roles identify what actors do. Functions and roles are structural elements rather than behavioural. The ArchiMate meta model can easily be modified to more clearly distinguish processes (start to end behaviours) from functions and roles (logical components). This table shows how elements can be renamed and moved.

Architecture layers	Behaviours over time	Addressable structures
Business layer	Business service	Business interface
Business layer	Business process	Function / Role / Actor
Applications layer	Application service	Application interface
Applications layer	Application process	Application function / Component
Infrastructure layer	Infrastructure service	Infrastructure interface
Infrastructure layer	Infrastructure process	Infrastructure function / Node

Principle 3c: Clustering discrete services makes a structural function, not a larger service

In addition to abstraction varieties mentioned above, simply erasing detail from a description is the simplest kind of abstraction. One way to erase details is to cluster several related things into a group, and then name the group of things, or the type of thing. Thus, discrete individuals become a set, things become a type, the unique becomes a collection.

Clustering different behaviour types into a group is how we design the logical structural elements we call interfaces, functions and roles.

A logical structure	clusters behaviour types that	more physical structures	are responsible for
An external interface	clusters behaviour types that	components	are responsible for
A business function	clusters behaviour types that	organisation unit actors	are responsible for
A role	clusters behaviour types that	human actors	are responsible for

Granularity is irrelevant here. A behavioural element (service or process) may be fine-grained or coarse-grained, depending on the granularity and the nature of the system that exposes or performs it. A single business service could be a project that runs from project request to delivery over years. But plurality is relevant. Joining several shorter behaviours in a longer behaviour makes one longer behaviour (the aggregate still runs from start to end or outcome). But clustering different units of behaviour into an aggregate using some other criterion is how we design a logical structural element. The aggregate is unlike an internal behaviour, and very like a role or function, or what TOGAF calls a logical component (the root entity of a “capability” to deliver that function using physical resources).

In short, if you cluster discrete services into a named group, you should represent it using the function or interface symbol.

Principle 3d: One-to-one relationships and synonym boxes can be redundant

In practice, some architecture diagrams are cluttered with redundant 1-to-1 relationships and synonym boxes. If a box called gardening is associated 1-to-1 with a box called gardener, then having two boxes is redundant. The verb-named box merely attaches an alternative label to the noun-named box. Defining a service as whatever a component does, one sees diagrams cluttered with 1-to1 relationships such as: transaction processing <is the service realised by> a transaction processor; message brokering <is the service realised by> a message broker; and customer relationship management is <is the service realised by> a customer relationship management system.

Similarly, if one component has one interface, found at the same address, there is no need to separate interface from component. If two components collaborate to support one interface, then that interface represents the collaboration, so there is no need to draw a collaboration box as well. If one process delivers one service, it may not help to separate service from process. And so on.