Premises and principles for business system modelling (Part 5)

By May 28, 2016 Articles

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

Leave a Reply

Login

Share This