Premise 5: Models are abstractions

How to align ArchiMate with UML and TOGAF

“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

Introduction. 1

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

Principle 5b: Architects both generalise and idealise system element types. 2

Principle 5c: Delegation is best distinguished from realisation. 3

Principle 5d: Enterprise architects model only a fraction of reality. 3

Principle 5e: Omission of detail 3

Introduction

Premise: All system descriptions abstract from operational systems that exist or are envisaged. Omission of detail is perhaps the most basic and universal abstraction technique. Several more specific varieties of abstraction are explored on the “Sense and nonsense in system theory page” at http://avancier.website. For example:

· After abstraction by delegation, a description of a client omits behaviour delegated to servers.

· After abstraction by composition, a description of a whole hides details of its parts.

· After abstraction by generalisation, a description of a generalisation omits details of any specialisations.

· After abstraction by idealisation, a description of a logical thing omits details of more physical refinements or concretions.

This table represents each of these four kinds of abstraction as a four-level hierarchy.

Delegation

Composition

Generalisation

Idealisation

Roles

Applications

System software

Hardware

Coarse-grained composite

Mid-grained composite

Fine-grained composite

Elementary part

Universal

Fairly generic

Fairly specific

Uniquely configured

Concepts

Logical Model

Physical Model

Physical Material

Servers

Decomposition

Specialisation

Realisation

There is no implication of correspondences along a row.

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

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 a longer behaviors (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.

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 behaviors (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 5b: Architects both generalise and idealise system element types

Enterprise architects usually strive to generalise components, services and interfaces – for reuse across an enterprise. This table show how TOGAF’s schema for architecture description artefacts (the Enterprise Continuum) maps levels of generalisation (columns) to levels of idealisation (rows).

Generalisation Idealisation	Foundation (Universal)	Common Systems (Fairly generic)	Industry (Fairly specific)	Organisation (Uniquely configured)
Requirements and Context
Architecture Continuum (Logical Models)	Foundation Architecture	Common System Architecture	Industry Architecture	Organisation Architecture
Solution Continuum (Physical Models)	Foundation Solutions	Common System Solutions	Industry Solutions	Organisation Solutions
Deployed solutions

Principle 5c: Delegation is best distinguished from realisation

It is common to describe or design a complex system by dividing it into hierarchical client-server layers. This simplifies the design of higher systems, which delegate to lower systems, which depend on lower systems, etc. Delegation enables a higher system to be described without little or no reference to how a lower system works.

ArchiMate speaks of realisation where delegation seems a better-fitting term. A client uses or delegates to a server; does not idealise it. An application delegates to devices; does not idealise those devices. A billing application delegates to a database software node or function; does not idealise it. Conversely, a server serves a client; does not realise it. A device serves system software; it does not realise it. A database system software node serves a billing application; does not realise it.

UML can show delegation from clients to servers using a dependency arrow. To this end, ArchiMate employs the “used by” relation in the reverse direction (meaning “serves”).

Principle 5d: Enterprise architects model only a fraction of reality

Enterprise architects do not describe all the busy, buzzing, confusion of reality; the astonishing variety of actors and activities in the conduct of business operations. They do not describe human biochemistry, human cognition or human social communication. They do not describe buildings, lifts, doors, vehicles, cabling and computer processor chips. They do not describe perhaps 99% of the biological and physical or material world that a business relies on.

TOGAF, in its development method and “enterprise continuum”, uses four different kinds of abstraction to classify and divide up architecture descriptions. This table shows each kind of abstraction as a four-level hierarchy; there is no implication of correspondences along a row.

The Architecture Development Method		The Enterprise Continuum
Delegation	Composition	Generalisation	Idealisation
Clients	Composed	Generic	Ideal
Roles	Enterprise / Strategy	Foundation	Requirements
Applications	x Segments	Common System	Architecture building blocks
System software	x * y Capabilities	Industry	Solution building blocks
Hardware		Organisation	Deployed Solutions
Severs	Decomposed	Specific	Real

Even the bottom (deployed solutions) row of TOGAF’s enterprise continuum is a huge abstraction from the reality of operational systems. For more, read “Abstraction in TOGAF and Zachman” on the “Sense and nonsense in system theory” page at http://avancier.website.

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