TOGAF metaphysics (types and instances)
One of about 300 papers at http://avancier.website. Copyright Graham Berrisford. Last updated 24/02/2017 01:20
This paper takes a metaphysical approach to how terms used in architecture frameworks could be more consistently defined.
Every architecture framework has to answer a metaphysical question.
How do architects describe the reality of an enterprise’s business systems?
There are conventions in logic and linguistics for how to define things.
This paper applies these conventions to address ambiguities in TOGAF.
It shows how to improve the consistency and coherence of the TOGAF glossary, content framework and meta model.
And suggests some refinements to definitions used in the ISO42010 standard.
Contents
Core
concepts in the TOGAF standard
Core
concepts in the ISO 42010 standard
On
definition by genus and differentiation
On
the type-instance distinction
A convention for the “intensional definition” of a term is to define it in the form “is a genus that has a differentiating property”.
E.g. A planet is a celestial body (a more generic type) that has an orbit around a star (a differentiating property).
The convention can be applied to define architecture description concepts.
First, we need to define general categories under which architecture description elements can be classified.
The table below classifies elements that appear in architecture descriptions in general, and in TOGAF in particular.
|
Element
type |
Classifies
elements that |
Exemplified
by |
||
|
Motivation and context
elements |
architects
respond to |
Driver, Goal,
Principle, Stakeholder |
||
|
System elements |
architects
describe/design |
|||
|
|
Behavioral
elements |
run from
start-to-end over time |
Process, Service |
|
|
Structural
elements |
exist independent
of behaviours they are engaged in. |
|||
|
|
Passive elements |
are acted on or
in |
Data entity,
Location |
|
|
Active elements |
act |
Physical
component, Organisation unit, Actor |
||
Then, TOGAF meta model types can be defined by adding a differentiator to a more generic type in the table above. E.g.
· A service is a behavioural element that can be requested by a client, and is defined declaratively so that it hides processes performed to realise the service.
· A process is a behavioural element that realises part or all of a service, and is defined procedurally in terms of discrete steps from start to end.
· A physical component is an active structural element that performs behaviours and is encapsulatable behind an interface.
· A logical component is a vendor-independent specification of a physical component, perhaps in the form of an interface definition.
Behavioral elements (think activities) run from start-to-end over time.
Services are behaviours that are defined declaratively and so encapsulate any process flow.
Processes are normally documented procedurally in terms of step-by-step flows.
Active structural elements (think actors) perform actions in response to events and service requests.
They have abilities; they need resources, and must be locatable or addressable.
(They do have a “thread of control” in the operation of a system, but are not defined as flows over time.)
The things we describe range from concrete things to abstract things.
Concrete things appear in observations of the physical matter and energy in the universe.
E.g. Mars is a structure – it is made of physical matter, observable in space.
And an orbit of Mars is a behaviour – it is a motion of physical matter, observable over time.
Abstract things appear only in descriptions.
The elements of an architecture definition document are abstract things.
The ISO 42010 standard is a description of a description (it is a meta description).
It describes an architectural description of a “software-intensive” system.
It defines description elements including view, viewpoint, model and model kind.
The standard might be clarified by making type-instance relationships explicit.
The table below lists type-instance relations in the ISO standard.
|
This complex type |
contains
types used by actors to govern |
these things |
|
The ISO 40210
Standard |
the
instantiation by documentation of |
Architecture descriptions |
|
A viewpoint |
the
instantiation by definition of |
Views |
|
A model kind |
the
instantiation by drawing of |
Models |
|
A meta model
type |
the
instantiation by documentation of |
Model elements |
|
An architecture
description |
the
instantiation by building of |
Operational systems |
The table below lists the reverse, the instance-type relations.
|
This thing |
exhibits
or embodies (gives values to) |
This complex type |
Found in |
|
An architecture
description |
the concepts and
rules defined in |
The ISO 40210 Standard |
ISO standards |
|
A view |
the more
abstract properties of |
A view type |
A viewpoint library |
|
A model |
the more
abstract properties of |
A model kind |
A modelling language |
|
A model element |
the more
abstract properties of |
A meta model type |
A meta model |
|
An operational
system |
the concepts and
rules defined in |
An architecture description |
Architecture repository |
Note how a thing can be both an instance and a type.
E.g. a computer program is both a thing that instantiates types in a programming language – and an abstract definition that typifies a run-time system.
An architecture definition in TOGAF is both a thing that instantiates types in the TOGAF meta model – and an abstract definition that typifies an operational business system.
Metaphysics is a broad area of philosophy; related to ontology.
Both address questions like: What is reality? How we know what it is?
What is a discrete thing in reality? How do we describe a particular thing?
How do we abstract from several real things to describe a general kind or type of thing?
Are there principles or qualities that apply to all things, or to subclasses of all real things?
The type–instance distinction is fundamental to any discussion of how we describe things.
· “Planet” and “orbit” are types.
· Mars can be described as an instance of the type “planet”.
· Any orbit of Mars can be described an instance of the type “orbit”.
A type is a definition (or a name for a definition) of properties exhibited or embodied by any thing that instantiates that type.
A generic type is a type (e.g. celestial body).that has properties shared by one or more subtypes (e.g. planet and comet).
A subtype is a type (e.g. planet) that extends the properties of a more generic type (e.g. celestial body) with its own properties.
To produce a consistent set of definitions one extends existing definitions using generalisation and specialisation (aka differentiation).
A convention for “intensional definition” is to define a term in the form “is a genus that has a differentiation”.
· A planet is a celestial body (a more generic type) that has an orbit around a star (differentiating property).
A type (say, “planet”) is realised by any thing (say Mars) that exhibits or embodies the types’ properties.
A type (say, “unicorn”) is unrealised until/unless there is a thing that exhibits or embodies the types’ properties.
An instance is a discretely identifiable thing that exhibits or embodies properties of a type.
A thing exhibits or embodies properties of a type when it is has (or is observed to have) values for those properties.
A thing can be an instance of many types: e.g. Mars is an instance of planet, spheroid, visible object etc.
And so, a thing may have values for many properties beyond those of any one type of which it is an instance.
The words type, property, concept, quality, feature and attribute are all used in discussion of how we describe things.
Sometimes they are used interchangeably; however, they tend to be used with different verbs.
Suppose we agree to define a rose bush as “a plant that is “thorny”, “flowering” and “bushy”.
We might say a particular rose bush
· instantiates those three types, or
· embodies those three concepts, or
· exhibits those three properties, or
· possesses those three qualities, features or attributes.
Property types (e.g. "height in metres" or "thorny") are often understood ontologically as concepts.
Property instances are sometimes understood as measured values (e.g. height = 1.74), and sometimes understood as more direct sensations or observations of reality (thorny = ouch!).
The type–token distinction is subtly different from the type-instance distinction.
It used in disciplines such as linguistics to clarify what words mean.
The sentence “they drive the same car” is ambiguous.
Do they drive the same type of car (the same model) or the same instance of a car type (a single vehicle)?
Clarity requires us to distinguish words that represent abstract types from words that represent things that embody or exemplify types.
The type–token distinction separates types (representing abstract descriptive concepts) from tokens (representing objects that instantiate concepts).
Some say types do not exist as tangible physical things.
You can show someone a particular bicycle, but cannot show someone the type "bicycle", as in "'the bicycle is popular."
However, types do exist in sense that they are perceptible in mental and documented models, if not tangible.
Some say tokens represent things that are tangible.
However, tokens can represent things that are intangible, yet perceptible by some other observation of physical matter and/or energy.
Consider tokens representing instances of the types “orbit”, "thought", "tennis match", "government" and "act of kindness".