Premise 6: Things are typified

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 6a: An actor or component type describes (each member in a set of) similar actors or components. 2

Principle 6b: Realisation has many possible meanings. 3

Introduction

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
View	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
Applications	ArchiMate: Application function / interface / service	is realised by	Application components
Infrastructure Technology	TOGAF: Logical technology component	is realised by	Physical technology components
Infrastructure Technology	ArchiMate: Infrastructure function / interface / service	is realised by	Infrastructure nodes