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.
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.
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).
|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|
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|
|Roles||Enterprise / Strategy||Foundation||Requirements|
|Applications||x Segments||Common System||Architecture building blocks|
|System software||x * y Capabilities||Industry||Solution building blocks|
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: 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.|
|UML||Time-bound behaviours||Addressable structures|
|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
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 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
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.
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.
|This logical type||relates to||These physical instances
|Applications||TOGAF: Logical application component||is realised by||Physical application components|
|ArchiMate: Application function / interface / service||is realised by||Application components|
|TOGAF: Logical technology component||is realised by||Physical technology components|
|ArchiMate: Infrastructure function / interface / service||is realised by||Infrastructure nodes|
Copyright Avancier Ltd 2016