4 years, 10 months ago

Premises and principles for business system modelling (Part 5)

Link: http://eapj.org/premises-and-principles-for-business-system-modelling-part-5-2/

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.



System software


Coarse-grained composite

Mid-grained composite

Fine-grained composite

Elementary part


Fairly generic

Fairly specific

Uniquely configured


Logical Model

Physical Model

Physical Material


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





Common Systems

(Fairly generic)


(Fairly specific)


(Uniquely configured)

Requirements and Context    
Architecture Continuum (Logical Models)Foundation ArchitectureCommon System ArchitectureIndustry ArchitectureOrganisation Architecture
Solution Continuum (Physical Models)Foundation SolutionsCommon System SolutionsIndustry SolutionsOrganisation 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 MethodThe Enterprise Continuum
RolesEnterprise / StrategyFoundationRequirements
Applicationsx SegmentsCommon SystemArchitecture building blocks
System softwarex * y CapabilitiesIndustrySolution building blocks
Hardware OrganisationDeployed Solutions

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.

SystemsTime-bound behavioursAddressable structures
TypesActivity 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.
InstancesActivities 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.

UMLTime-bound behavioursAddressable structures
TypesOperation typesClasses
InstancesOperation instancesActive 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 aspectType in modelIndividual in operational system
Active structureRoleActor: has a state and relationships to other actors
BehaviourProcessPerformance: runs from start to end according to business rules
BehaviourEventOccurrence: triggers a process performance
Passive structureData objectData 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

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

Logical typesInstances in timeInstances in spaceLogical types
ExternalBusiness servicesService occurrencesBusiness interfaces?Service level agreements
InternalBusiness processesProcess performancesOrganisation unit actors

Human actors

Business functions


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 thingsYou might sayThese more concrete things
Classesare realised by instantiation inObjects
Methods (services)are realised by implementation inMethod bodies (processes)
Abstract classes (interfaces)are realised by implementation inConcrete classes (components)
UML classesare forward engineered intoJava 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 typesYou might sayPhysical instances
Data typesare realised by instantiation inData structures/items
Eventsare realised by instantiation inOccurrences
Processesare realised by instantiation inPerformances
Rolesare realised by instantiation inActors

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 elementsYou might sayInternal elements
Servicesare realised by implementation inProcesses
Interfacesare realised by implementation inComponents

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 ABBsYou might sayPhysical ABBs
Business functionsare forward engineered intoOrganisation unit descriptions
Logical application componentsare forward engineered intoPhysical application components
Logical technology componentsare forward engineered intoPhysical technology components

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

Logical ABBsYou might sayPhysical ABBs
Business objectsare forward engineered intoData objects in a data model
Data objectsare forward engineered intoDatabase 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.



This logical typerelates toThese physical instances

and realisations

ApplicationsTOGAF: Logical application componentis realised byPhysical application components
ArchiMate: Application function / interface / serviceis realised byApplication components


TOGAF: Logical technology componentis realised byPhysical technology components
ArchiMate: Infrastructure function / interface / serviceis realised byInfrastructure nodes

Previous article in this series

Copyright Avancier Ltd 2016