From the Editor: Graham Berrisford from Avancier Ltd has provided us with a series of articles related to modelling of business systems. This is part 3. Have a read and let us know what you think in the comments section below.

Behaviour (time bound)

The second article in this series listed 6 premises; this article explores the second premise.

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

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

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.

So how do you 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.

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

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

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 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 discrete unit of behaviour that proceeds from specific event to specific outcome, then contrary interpretations of the term “service” would be unlikely.

Some suggest discrete event-driven services are too fine-grained for architects to worry about. This is misleading. Some services (cf. use cases) are short and/or minor; others are long and/or mission-critical. In practice, architects are concerned with important services. 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 in the next article 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 a 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 differences.

Next time?

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

Previous article in this series | Next article in this series

Copyright Avancier Ltd 2016