Premise 2: Behaviours are time bound

How to align ArchiMate with UML and TOGAF

Copyright Avancier Ltd 2106


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


Introduction. 1

Behaviour/structure as a time/space distinction. 2

ArchiMate view of structure and behaviour 3

Principle 2a: An event type describes (each member in a set of) similar occurrences that trigger behavioural elements  4

Principle 2b: Architects model several kinds of trigger 5



Premise: All regular behaviours in a business system are triggered by discrete events, and run over time.


Encapsulation of regular behaviours behind services

How we model the structure and regular behaviours of a business system is based on the premises of system theory and logic. The regular behaviours are commonly called processes or services. A service does not expose behaviour; it is the behaviour that is exposed. The table below abstracts a general definition of “service” from those in the TOGAF and ArchiMate standards.


TOGAF’s definition

ArchiMate’s definition

Generally speaking, a service is

“an element of behaviour that provides specific functionality

“a unit of functionality that

A discretely invokable behaviour (short or long) that

in response to requests from actors or other services.

a system exposes to its environment,

is triggered by an event/input received from client actors or components,

A logical representation of a repeatable business activity,

hides internal operations,

is defined in a service contract that encapsulates internal process(es),

has a specified outcome,

provides a value,

produces results of value to clients, and is

is self-contained, is a ‘‘black box’’ to its consumers.”

accessible through interfaces.”

presented for access in one or more interfaces.


Here are some example services drawn from the ArchiMate 2.1 standard: Create policy type, Apply for insurance, Take out policy, Renew policy, Collect premium, Bill customer, Open account, Identify account status, Transfer money, Retrieve customer policy record, Register claim, Assess damage, Pay claim, Scan document, Print document, Deliver message.


A service is often gathered with other services into a coarser-grained interface or service level agreement document. Some internal services (and components) are too fine grained for architects to consider. But architects certainly do identify and name discrete services. That is how TOGAF expects architects to specify the behaviour(s) required of a business or other system of interest.


Every end-to-end process (be it called a scenario, workflow, value stream or use case) can be encapsulated and defined as a discrete service. However long it takes (minutes, hours, days, weeks....) the service is a discrete stimulus-response behaviour, which can be defined in a service contract.


The structure/behaviour distinction

This paper goes on look at the basis of the structure/behaviour distinction in logic. General system theory proposes an activity system is encapsulated inside its environment behind an I/O boundary. Architects describe activity systems by typifying regular behaviours (discrete processes over time) performed by actors and/or components (discrete things in space) in response to events (discrete stimulae) received through the I/O boundary.


The structure/behaviour distinction, fundamental to system theory, seems clear in simple illustrations.



Structural elements

Behavioural elements

Solar system


orbiting the sun

Human body

hearts, lungs and skin

breathing, running and perspiration

Domestic service

butlers, guests and silverware

greeting guests and polishing silver

OO software

interfaces, classes, objects

operations and interactions


Yet the structure/behaviour distinction can be confusing. In a sense, every active structure element is behavioural, and every behaviour has a structure. A butler’s role or function is defined by behaviours performed. Each behaviour a butler performs has a logical structure over time. If you remove all behaviour from the description of a role or component, then you are left with nothing but passive structure. Just as removing all operations from a class definition in UML leaves only data types.


How to draw the behaviour/structure distinction in a way that is unambiguous? The distinction drawn in UML is underpinned by unambiguous concepts of time and space. The distinction drawn in ArchiMate is underpinned by the linguistic concepts of subject, verb and object (SVO); these concepts are fuzzier and lead to some confusions in interpreting the ArchiMate standard.

Behaviour/structure as a time/space distinction

Physicists consider our world to be embedded in a four-dimensional space-time continuum. At run-time, an individual actor or component responds to messages, in the light of retained memories, by performing appropriate behaviours and sending messages. Although it does have its own “thread of control”, it is called a structural element because it is a structure than can be addressed (located in space) and prompted to do work (over time).


General system theory proposes an activity system is encapsulated inside its environment, behind an I/O boundary. Enterprise architects describe activity systems by typifying

·         regular behaviours (discrete processes over time) which are performed by

·         actors and/or components (discrete things in space) in response to

·         events (discrete inputs or triggers).


This table presents these concepts in a two-by-two grid.


Time-bound behaviours

Addressable structures

External view

Events and results

I/O boundary

Internal view

Regular behaviours

Actors or components


The external view of a system’s behaviour is composed of input events and output results that external entities can see. For example, you can send and receive emails with no sight or knowledge of how your email system does that. An external structure is a place where external entities can trigger and/or see the result of behaviours. For example, an email application has two interfaces – one for people and one for other applications. The table below exemplifies the table above.


Time-bound behaviours

Addressable structures

External view

Send email, Receive email

Human interface, API

Internal view


Email application


The structure/behaviour distinction is only secondarily a linguistic distinction; it is primarily a space-time distinction. Our two basic premises can be refined to make this distinction clearer.

·         All regular behaviours in a business system are triggered by discrete events, and run over time.

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


Accepting these premises leads to a simple and robust generic meta model.


Time-bound behaviours

Addressable structures

What happens, what is done

What can be found to get things done

External view

What external entities see

Events and Services


Internal view

Inner workings


Actors and Components


General system theory proposes you take a holistic view of a system’s behaviour. To architect a system, the principle is to define the required behaviours, then hire, buy or build structural elements to perform those behaviours. (By contrast, to analyse a baseline system, TOGAF reverse engineers a catalogue of services from existing structural components.)

ArchiMate view of structure and behaviour

The ArchiMate modelling language is inspired by the SVO grammar of natural language sentences. Most human languages use an SVO or SOV sequence in sentences. Curiously, the ArchiMate generic meta model is presented in the OVS sequence (little used outside of “Klingon”). The table below maps some key words used in the ArchiMate modelling language to the OVS structure of its generic meta model.

Natural sentence parts




ArchiMate  system aspects

Passive structure element

Behaviour element

Active structure element

ArchiMate  system elements

Business object, Data object

Service, Process, Function

Actor, Component, Node, Interface


Linguistic concepts are flexible. Not all sentences have a subject and an object. One thing can be both subject and object within one sentence. Nouns are used as verbs; verbs as used as nouns. Questions to be explored include: If a multi-service component is called structural, then why is a multi-service function (aka logical component) called behavioural?


This table shows core concepts in ArchiMate’s generic meta model.




External view



Internal view

Internal Behavioural Elements

Internal Active Structural Elements


The vocabulary used in the bottom row of the table above is clumsy. Why not use more natural terms such as activities and actors, or performances and performers, or operations and operators, or workings and workers? ArchiMate cannot do this because it does not hold to the space/time distinction drawn above.


The next table shows words ArchiMate uses in the external/internal and behaviour/structure dimensions of each of the traditional architecture domain layers.

Architecture layers



Business layer

Business service

Business interface

Business process / Function

Role / Actor

Applications layer

Application service

Application interface

Application function

Application component

Infrastructure layer

Infrastructure service

Infrastructure interface

Infrastructure function



In UML, multi-operation classes are structural elements; start-to-end operations are behaviours. By contrast, ArchiMate’s structure/behaviour distinction is unclear, arguably because it confuses structure with behaviour and type with instance, and relies instead on the noun-verb distinction in natural language. We can turn any noun (say broker) into a verb (say brokering) without saying much of significance about the architecture of a system. Brokering is not a service in the sense defined by ArchiMate “a unit of functionality with a specific outcome”. See Premise 3 for how to better align ArchiMate with system theory.


Remember the premise: All regular behaviours in a business system are triggered by discrete events, and run over time. Enterprise architects take a service-oriented view of business systems in which actors and components perform behaviours in response to discrete event messages. To define the details of one named behaviour, you define its inputs, outputs, preconditions, post conditions and non-functional characteristics. (You can do this using something like a service contract or use case template.)

Principle 2a: An event type describes (each member in a set of) similar occurrences that trigger behavioural elements

External events trigger actors or components to change the internal state of a system and/or to provide services. Some services/processes do not change the state of the systemSome events fail, some trigger only reporting services/processes. If an event-triggered process consumes a resource (say electricity) that is not included in the system model, then that state change is outside the scope of the system of interest.


WSDL is an interface definition language used to define “web services”. Where to place a web service in this table?

Architecture layers



Applications layer

Application service

Application interface

Application function

Application component


You might think to represent a web service using ArchiMate’s application service symbol, and represent the internet using the application interface symbol. What does the ArchiMate standard actually say? It defines an interface as a structure that exposes one or more services, each being a unit of functionality with its own specific outcome.

·         As ArchiMate defines an interface, so, a web service is a point of access where one or more web service operations are exposed or available to clients.

·         As ArchiMate defines a service, so, a web service operation is a unit of behaviour with a specific outcome that a web service exposes to its clients, while hiding internal procedures.


Architecture layers



Applications layer

Web service operation

Web service

Application process

Application component


ArchiMate usage and illustrations diverge from its standard concept definitions. Practice diverges from system theory where, for example, applications are labelled “services” (or “micro services”), interfaces are labelled “services”, platform communication channels are labelled “business interfaces”. The result is confusion of structure with behaviour, confusion of architecture layers and a loss of coherence.


If we all agreed that a service is a unit of behaviour that proceeds from event to outcome, then contrary interpretations of the term “service” would be unlikely. A discrete event may represent or trigger a state change in a system; or, it may merely trigger that system to report its current state. E.g. Gas flows continually through a meter, there are no discrete events in that physical reality. Gas consumption is modelled in the display of the meter (a mechanical information system); the discrete events here being consecutive increments of the number on display. A human meter reader records the number on display at the time of his/her visit; a discrete event here is message from the meter reader to the billing system which records that visit and the state change since the meter was last read.


Some suggest discrete event-driven services are too fine-grained for architects to worry about. Some services are short; some are long. Architects are concerned with important services, be they short or long. Where a system or component provides too many services to show on a diagram, the architect may join shorter services in a longer service, or else cluster services together in another way. But clustering services creates a logical function/component, not a larger service. See Principle 3c for elaboration of this point.


ArchiMate does not presume that behaviour is event-driven, and it blurs the concepts of event, process and state change. It says an event can start or result from a behaviourIf the first step in a process flow is called an event and the last step is called an event, then what is the difference between an event and a process step? It also blurs the concepts of event and state change. If every event is a state change, then which event (the first or last in a process flow) is the state change made by the process? If those start and end events are discrete state changes, then surely every step within the process flow is equally well regarded as state change?

Principle 2b: Architects model several kinds of trigger

In UML, an arrow from behaviour A to B is a transition arrow, it implies transfer of control. In ArchiMate, a trigger from A to B might or might not be a transition arrow. It describes a temporal or causal relationship between instances of A and B. Does it imply A stops and B starts? No. Where A and B are coarse-grained functions, it usually means that some part within A triggers the some behavioural element within B, and there is usually an accompanying data flow.


Architects may define a trigger that is a transition, or not; a trigger that represents instantiation of a structural element; a trigger that represents a synchronous or asynchronous invocation. ArchiMate should at least discuss how architects address these architecturally significant matters.



Copyright Avancier Ltd 2106