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.
Principles
Behaviour/structure
as a time/space distinction
ArchiMate
view of structure and behaviour
Principle
2b: Architects model several kinds of trigger
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.
System |
Structural elements |
Behavioural elements |
Solar
system |
planets |
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.
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.
System |
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.
Email |
Time-bound behaviours |
Addressable structures |
External view |
Send email, Receive email |
Human interface, API |
Internal view |
(invisible) |
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.
System |
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 |
Interfaces |
Internal
view Inner workings |
Processes |
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.)
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 |
Object |
Verb |
Subject |
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.
ArchiMate |
Behaviours |
Structures |
External view |
Services |
Interfaces |
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 |
Behaviours |
Structures |
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 |
Node |
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.)
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 system. Some 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 |
Behaviours |
Structures |
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 |
Behaviours |
Structures |
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 behaviour. If 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?
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