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

Elaboration of three principles

The second article in this series listed 6 premises. This article expands on some of the principles previously explained in those premises, and summarizes the series.

Principle 5a: Decomposing active structure and behaviour views identifies the same elementary actions

Physicists consider our world to be embedded in a four-dimensional space-time continuum. It is called a “continuum” because it is assumed that space and time can be subdivided without any limit to size or duration. Business system descriptions can be hierarchically divided by space/structure and by time/behaviour.

Structural composition/decomposition

A structural view defines what a system is made of. It defines actors and components that perform behaviour (along with interfaces and data structures). Structural decomposition successively divides space into smaller spaces. Biologists describe a body in terms of organs, then tissues, then cells, then organelles. Architects organise a large system into large components which are subdivided into smaller ones and so on. A higher level system can be described only in terms of next-most coarse-grained components, hiding the internal details of finer-grained components.

Behavioural composition/decomposition

The behavioural view of a system defines what a system does, how it works. It defines regular services and processes that run from start to end, repeatedly. Behavioural decomposition successively divides time into shorter durations. We can divide a long process into short steps, divide those steps into shorter steps, and so on. A higher level process can be described only in terms of next-most coarse-grained process steps, hiding the internal details of finer-grained steps.

Functions can be seen as logical components. Business functions can be seen as logical organisation units. A functional decomposition hierarchy groups activities in a structural view. By contrast, a process decomposition hierarchy groups activities in a behavioural view. So, if both hierarchies are decomposed to the same level, they must both descend to the same elementary activities. This principle is evident in the structured analysis techniques used in EA frameworks like Avancier Methods, EA3 and TOGAF. The elementary activity may be called an elementary business function and/or an elementary business process.

Decomposing behaviour and active structure views to the same level

In UML, the fundamental or elementary unit of behaviour – the finest-grained behaviour in the system model – is called an “action”. Joining actions in a sequential flow is how we define longer behaviours (process, workflow, state machine or interaction). Clustering actions by some other cohesion criterion is how we design structural elements (functions, components, interfaces etc. ArchiMate should address the principle that active structure and behaviour views are decomposable to the same elementary activities, and how to represent this conjunction using symbols in diagrams.

Principle 5e: Omission of detail

Omission of detail is perhaps the most basic and universal abstraction technique. TOGAF implies omitting intermediate entities that are often shown in ArchiMate diagrams.

For example, this ArchiMate style model.

Element	Relation	Element	Relation	Element
Service	Assigned from	Interface	Part of	Component
Service	Realised by	Process	To	Component

Is typically reduced in TOGAF to this model.

Element	Relation	Element
Service	Realised by	Component

On the other hand, it isn’t always possible or helpful to derive a direct relationship from direct ones. Sometimes because there are several possible relationship paths. Sometimes because boxes represent large and complex types, composed of many smaller simpler elements, and lines relating instances of source and target types often connect elements within source and target instances. And sometimes because relationships can be optional.

E.g. ArchiMate says that if A-triggers-B-triggers-C, then A-triggers-C. Is this necessarily true? What if A triggers a behaviour within B that has no relationship to C? Or triggers a behaviour that chooses whether to trigger C or not? If Strategy triggers Marketing & Sales triggers Complaints & Compensation, is it appropriate to say Strategy triggers Complaints & Compensation?

E.g. ArchiMate says that if A-is-associated-with B-is-associated-with-C, then A-is-associated-with-C. What if A is associated with only a part of B that is unrelated to C? If the associations are Customer-Movie Showing-Movie-Actor, is it appropriate to say Customers are associated with Actors?

In one sense, every part of a system is associated with every other part, directly or indirectly, else there would be separable systems. But it isn’t architecturally meaningful or useful to associate every part with every other part.

Principle 1d: Business interfaces are not platform communication channels

A social, business or software system is encapsulated logically rather than physically. An actor-to-actor or business-to-business interfaces may be defined in a service level agreement document that lists invokable business services. Since actors and components are distributed, they must exchange discrete communication events to invoke behaviours and respond to invocations, and there must be a physical communication channel along which the communication events can be passed. There is confusion in ArchiMate examples between the concept of a logical business-to-business interface (declaring what services may be invoked), and the physical infrastructure channels via which services may be invoked.

This table puts business function where it seems to belong, but highlights the question of where business interface belongs.

View	Behaviours		Structures
View	Logical types	Instances in time	Instances in space	Logical types
External	Business services	Service occurrences	Business interfaces?	Service level agreements
Internal	Business processes	Process performances	Organisation unit actors Human actors	Business functions Roles

Since ArchiMate suggests an interface is an access point to services, it is placed as an instance above. But business architecture diagrams showing business interfaces called “telephone” or “web” are highly questionable. These are generic infrastructure devices or communication paths. These are not (as ArchiMate insists an interface should be) bound to one and only business role or actor.

B2B and B2C communications depend on shared communication infrastructure, for example:

Face to face speech – mouth to ear over the physical medium of sound waves.
Telephone speech – mouth the ear over the deep communication stack of a Telco network.
Snail mail – writing to reading using paper over the communication stack of a postal service.
Email – writing to reading using keyboard and screen over SMTP/IMAP over TCP over IP over Ethernet over physical IT media.

We do view business, applications and infrastructure domains as client-server layers. And in an “open” (rather than closed) client-server architecture you can skip layers. So in playing a business role, a human actor might directly invoke an infrastructure service. But generic infrastructure devices and communication paths are not business-specific system interfaces.

So what is a business-specific interface? Some kind of service level agreement defines (logically) what services a business requires or provides. This logical interface might then be realised in an application interface via which clients can invoke individual service occurrences. Or in telephone answering system that exposes domain-specific services (press 1 for this, 2 for that) to customers. Often it is realised in formal requests for work and in less formal inter-human communication.

Here are some concepts entangled in the idea of an interface, which ought to be disentangled.

Service level agreement: a contract or other form of interface definition that declares what services clients can invoke, but is not run-time access mechanism.
Controls: mechanisms (including user interfaces) that give clients tools to invoke domain-specific services directly.
Directory: a “direct broker” or introduction agent that declares services and provides their addresses to clients.
Façade: an “indirect broker” component that accepts events and service requests and passes them to server components.
Communication stack: platform technologies used in the communication paths between actors or components.

Conclusions and recommendations

It is very difficult (unnatural) to use words in a disciplined way. But it is the responsibility of a professional to understand which domain-specific words are ambiguous, where misunderstandings can occur and to specify solutions clearly. Standard modelling languages are only a part of the answer.

There is widespread ignorance of system theory premises. This makes it hard to teach people architecture concepts, and leads to inconsistent use of modelling languages. Using the same symbols as somebody else doesn’t mean you are using the same language. And rather too often, a diagram reader is not sure what the diagram drawer meant to say.

Words like function and service are used variously and vaguely in natural language. Asked to define their meanings in modeling language, a committee may try to please all by relaxing the definitions to the point of ambiguity. And so, it becomes impossible to convey valuable and necessary concepts with any certainty. Compromising symbol definitions to suit all comers and all practices leads to inconsistency and incoherence, and makes it difficult to teach architects.

Of course, many use system modelling tools as they would use PowerPoint. There is a combination of laziness, questionable examples and low quality training. But the issues raised in this paper can be addressed easily enough, and surely ought to be addressed rather than swept under the carpet. We have to bite the bullet and used a “controlled vocabulary” – rather whatever seems the most natural or common language today. Here is an attempt to define the core terms in TOGAF.

External entity	[A logical or physical component] outside the business or system of interest, which interacts with that business or system by requesting or supplying services.
Actor	[A physical component] or individual able to play one or more roles in the performance of processes. (Where non-human actors are represented as application and/or technology components, then the actors must be human.)
Organisation unit	[A physical component] or individual node in a management structure, able to fulfil one or more functions. It should have goals and objectives with measures, and a manager.
Role	[A logical component] realised or played by individual actors, specified in terms of services provided and/or processes performed and abilities required.
Function	[A logical component], a cohesive cluster of behaviors required of any organisation unit that fulfils the function, specified in terms of services provided and/or processes performed and abilities required. (It is a logical business capability, not to be confused with a managed organisation unit or discrete business service.)
Business process	[A process] that is performed by the actors in a business, with or without information technologies.
Business service	[A service] that can be requested of a business, or a component thereof. (Not to be confused with a business function .)
Data entity	[A data element] composed of data items that represent facts about a discrete business entity or event. It may be specified at a conceptual, logical or physical level. It may be mapped to data stores and/or data flows input to or output from IS services.
IS (app) service	[A service] that can be requested of a business-oriented application component, by a human actor or another application component.
Application component	[A component] of business-oriented software (e.g. CRM, Billing). It is specified logically by the IS services it provides, and sometimes also by the data entities it maintains, and/or physically as a vendor/technology specific product that can be hired, bought or built.
Platform service	[A service] that can be requested of a technology component by an application component or another technology component.
Technology component	[A component] of generic infrastructure software (e.g. OS, DBMS). It is specified logically by the platform services it provides, and/or physically as a vendor/technology specific product that can be hired or bought.

ArchiMate could remain intentionally non-rigorous, defined in a way that ambiguous in places and in regardless of wider system theory in places. This paper suggests how to use ArchiMate symbols in a way that is more compatible with the system theory premises that underpin UML and TOGAF. Options include:

Explain ArchiMate’s structure/behaviour distinction is different from that in other standards, and change the standard’s definitions of “service” and “interface” to resemble what example diagrams often show (though this will further confuse structure with behaviour and abstract with concrete).
Align ArchiMate’s premises with system theory principles, address all Principles in this paper and revise example diagrams to fit.
Add this paper to the standard as an appendix on customising ArchiMate to fit UML and TOFAF (current guidance on this is naïve and inadequate).

The principles in this paper are drawn from papers on the “Sense and nonsense in system theory page” at http://avancier.website. That page describes general principles that underpin enterprise architecture. It explores system theory, type theory and information theory; and adds dashes of biological evolution, sociology and philosophy into the mix.

P.S. What about steel mills, car production lines and other such stock-and-flow systems? Nobody who designs steel mills calls themselves an enterprise architect; and nobody who calls themselves an enterprise architect designs steel mills. There is a method for modelling the continuous dynamics of stock-and-flow systems, called “system dynamics”. But even system dynamics can be seen as an abstraction from discrete event dynamics – as explained in detail at the Avancier website.

Previous article in this series