TOGAF metaphysics (types and instances)

One of about 300 papers at 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.


Core concepts in the TOGAF standard. 1

Core concepts in the ISO 42010 standard. 2

Footnotes on metaphysics. 3

On definition by genus and differentiation. 3

On the type-instance distinction. 4

On the type-token distinction. 4


Core concepts in the TOGAF standard

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


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

Core concepts in the ISO 42010 standard

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


A model kind

the instantiation by drawing of


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.

Footnotes on metaphysics

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?

On definition by genus and differentiation

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

On the type-instance distinction

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

On the type-token distinction

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