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 4. Have a read and let us know what you think in the comments section below.

Premise 3:  Structures are space bound

The second article in this series listed 6 premises; this article explores premise 3 and 4.

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 process	Function / Role / Actor
Applications layer	Application service	Application interface
	Application process	Application function / Component
Infrastructure layer	Infrastructure service	Infrastructure interface
	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-to-1 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.

Premise 4: Data conveys meaning

Premise: A data object contains a data structure or item that is meaningful or valuable to its creators and users. Business system modellers need to know what data passes between actors or components what data is stored in which containers. Enterprise architects model “information-intensive” business systems in which essential elements include data flows (messages of all kinds) and data stores (memories).

ArchiMate is thin on data architecture. Is its “data object” a message or data flow? a memory space or data store? or a discrete chunk of information conveyed inside a message or retained in a memory? The premise here is that each data object is a data item or larger data structure that is meaningful or valuable to its creators and users.

ArchiMate does not talk about the data structures contained in data objects, but they are there. A data object can be small or large. It could be a single data item, or a customer entity with several attributes. It could be an aggregate entity, such as a customer, with orders and order items. Or a large and complex data structure containing customers, orders, order items and product types. However small or large, the content of a data object can be defined in a data model.

Principle 4a: A message or data flow conveys a data object from a source to a target.

A discrete message or data flow (or interface in TOGAF) conveys a data object from a source to a target. Messages occupy space and take a physical form (e.g. digital or paper). You can draw a flow arrow to show the movement of data/information/value between source and target elements. You can elaborate every data flow relationship using two arrows and a data object thus [source element —> data object —> target element].

Note that any discrete service may consume and/or return a data flow, even though it is not shown on a diagram.

Principle 4b: A memory or data store retains a data object for the use of actors or components performing behaviours.

A discrete memory or data store (or data component in TOGAF) retains a data object for the use of actors or components performing behaviours. Memories occupy space and take a physical form (e.g. digital or paper). The purpose of showing data stores in a system model is to identify independently-maintained memory spaces. Especially ones that hold large and complex data structures, composed of many smaller data structures and items.

How to represent a data store? ArchiMate has no data store symbol, and has various symbols that might be used.

• Data object – can represent a data structure at any scale from atomic data item to large and complex data structure.
• Artifact – can represent a deployable data structure definition (e.g. a message schema or database schema)
• System software – can represent data management system (e.g. a DBMS).
• Application component – can represent a data server layer that encapsulates a data store or other data source.

It isn’t obvious which symbol is best. You may say a data store is a passive structure that does not perform behaviour. So a data store can be modelled as a data object – perhaps a large and complex one. At run-time, a data store instantiates the concepts defined in any associated logical data model; it contains actual data (e.g. rows in database tables). If it is to be useful it has to be encapsulated in some way by put/get services. Which means it could be modelled as an application component. So, should we draw a data object or an application component? ArchiMate will not let you draw data flows to or from data objects, so if you want to do that, then you have to represent a data store as an application component.

Principle 4c: The cardinality of associations is important

ArchiMate doesn’t have a way to show the cardinality of an association relationship. The result is that people use composition to mean a 1-N association and use aggregation to mean an N-N association. Just as we need AND and OR symbols to connect relationships, we need a cardinality symbol (and better a crows foot than an asterisk) to show where the system element at one end of a relationship can appear as several instances in the operational system.

Principle 4d: Data objects are neither objects nor classes in the OO sense

A business object or data object is not an object as in OO programming. Nor is it a class in a UML class diagram (though it could possibly correspond to a class). To avoid confusion, you could reasonably refer to business/data objects as business/data types. A data type describes a data structure which encodes information that has meaning or value to its senders and receivers.

Previous article in this series | Next article in this series

Copyright Avancier Ltd 2016