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

Premise 5: Models are abstractions

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

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

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

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.

Premise 6: Things are typified

Premise: Architects normally model types rather than instances. An operational system features individual things (occurrences of structure and performances of behaviour) that are complete, precise and concrete. By contrast, architects create highly abstract models. The models feature types of things; the types are abstract, incomplete, and may be fuzzy.

The type/instance distinction is usually interpreted as a description/reality distinction. An instance is anything that embodies or exhibits the properties of a type. Instantiation of a structural type is sometimes called concretion. Instantiation of a behavioural type is different. A symphony performance is an instance of a symphony. A car’s manufacture is an instance of a car manufacturing process. A calculation of a rectangle’s area is an instance of a rectangle area calculation.

Generally, systems are composed of actors (addressable structures) who perform activities (time-bound behaviours). Both actors and activities appear as descriptive types and operational instances.

Systems	Time-bound behaviours	Addressable structures
Types	Activity types describe units of behaviour that are transient. E.g. A service contract, process flow chart or interaction/sequence diagram.	Actor types describe attribute types an actor should have and activity types performable by an actor. E.g. A role. A function. An interface definition.
Instances	Activities are transient performances – run from start to end over time. E.g. Any process that instantiates the logic in a service contract, a flow chart or interaction/sequence diagram.	Actors are addressable in space, perform activities, have a thread of control and a current state. E.g. Actors who play roles. Organisation units that realise functions. Component instances that realise interfaces.

For example, in UML, a class identifies the behaviour types performable by objects that instantiate the class.

UML	Time-bound behaviours	Addressable structures
Types	Operation types	Classes
Instances	Operation instances	Active objects

Natural language often blurs the distinction between types and instances of system element. Terminology in UML and ArchiMate can be used to distinguish them thus:

• An active structural element type describes (each member in a set of) similar actors, components or nodes.
• A behavioral element type describes (each member in a set of) similar performances
• An event type describes (each member in a set of) similar occurrences.
• A data type describes (each member in a set of) similar data structures or items.

This table maps the types and instances above to ArchiMate’s system aspects.

ArchiMate aspect	Type in model	Individual in operational system
Active structure	Role	Actor: has a state and relationships to other actors
Behaviour	Process	Performance: runs from start to end according to business rules
Behaviour	Event	Occurrence: triggers a process performance
Passive structure	Data object	Data structure/item: encodes specific meaningful information (may be created, moved, changed or destroyed).

Mostly, architects model types of things. Architects almost never refer to individual event occurrences or process performances, but they do sometimes name individual actors or components and perhaps even values of individual data structures/items (invariants).

Principle 6a: An actor or component type describes (each member in a set of) similar actors or components.

Actors are assigned to roles. Strictly, what instantiates a role is the assignment of an actor to that role. However this instantiation is usually viewed from the role end (rather than the human being end). So, organisation unit managers and enterprise architects see actors as instantiating roles. What actors are, and do, outside of playing roles in a system, makes no appearance in our business system models.

The table below shows organisation units instantiating functions in a way that is analogous to actors instantiating roles

Business	People	Organisation
Types	Roles	Functions
Instances	Actors	Organisation units

ArchiMate does not explicitly distinguish types from instances, but it usually models types. You would not model one individual car’s manufacture, but might model a general car manufacturing process. You can however model one individual actor assigned to play a role. This table extends the two-dimensional grid to show type/instance distinctions that could be drawn in ArchiMate.

View	Behaviours		Structures
	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

Curiously, ArchiMate positions functions as behaviour elements. This table finally puts business function where it seems to belong. But now, the position of business interface is questionable. See Principle 1d.

Principle 6b: Realisation has many possible meanings

System models hide the infinitely detailed physical characteristics of real systems in operation. ArchiMate says “realization links a logical entity with a more concrete entity that realizes it”. It is bad practice to define a term using the term itself since it doesn’t help the reader. It leaves realisation open to at least four possible meanings, illustrated here in terms of object-oriented software concepts

These more logical things	You might say	These more concrete things
Classes	are realised by instantiation in	Objects
Methods (services)	are realised by implementation in	Method bodies (processes)
Abstract classes (interfaces)	are realised by implementation in	Concrete classes (components)
UML classes	are forward engineered into	Java classes

But ArchiMate examples use the realisation arrow for a peculiar selection of these meanings.

You might hear realisation used to mean instantiation of a type by things in reality, as in this table.

Logical types	You might say	Physical instances
Data types	are realised by instantiation in	Data structures/items
Events	are realised by instantiation in	Occurrences
Processes	are realised by instantiation in	Performances
Roles	are realised by instantiation in	Actors

But ArchiMate does not appear to use realisation in this instantiation sense.

You might say an external service or interface is realised by implementation in one or more internal processes or components.

External elements	You might say	Internal elements
Services	are realised by implementation in	Processes
Interfaces	are realised by implementation in	Components

Curiously, ArchiMate says the former but not the latter (it says instead that an interface is a part of a component.

You might notice TOGAF makes a big thing of defining logical Architecture Building Blocks (ABBs) above and before physical Solution Building Blocks (SBBs). The logical ABB descriptions are forward engineered into SBBs, which are still only descriptions and “highly abstracted” from tangible or run-time components.

Logical ABBs	You might say	Physical ABBs
Business functions	are forward engineered into	Organisation unit descriptions
Logical application components	are forward engineered into	Physical application components
Logical technology components	are forward engineered into	Physical technology components

ArchiMate adopts this refinement approach, but only in the data architecture domain.

Logical ABBs	You might say	Physical ABBs
Business objects	are forward engineered into	Data objects in a data model
Data objects	are forward engineered into	Database tables in a database schema or artefact

ArchiMate offers no idealisation-realisation hierarchy for active structural elements. However, the table below (using a mix of TOGAF and ArchiMate terms) shows where a realisation arrow might be used to relate logical elements to more physical/real elements.

Architecture domains	This logical type	relates to	These physical instances and realisations
Applications	TOGAF: Logical application component	is realised by	Physical application components
	ArchiMate: Application function / interface / service	is realised by	Application components
Infrastructure Technology	TOGAF: Logical technology component	is realised by	Physical technology components
	ArchiMate: Infrastructure function / interface / service	is realised by	Infrastructure nodes

Previous article in this series | Next article in this series

Copyright Avancier Ltd 2016