The nub: the philosophy and semantics of system description

Copyright 2017 Graham Berrisford. One of about 300 papers at Last updated 09/01/2018 21:57


Enterprise architecture is about business system planning.

This paper outlines the philosophy and semantics of system description.

It is written with respect to what Charles Darwin wrote on evolution and W Ross Ashby wrote on system theory.


Two kinds of system.. 1

System description in general 2

The philosophy underlying system description. 3

The semantics of system description (after UML) 4

Ten things to know about systems. 7

Further reading. 11


Two kinds of system

The systems of interest to us have both structures and behaviors - actors and activities.

However, actor-oriented and activity-oriented definitions of a system are very different.

Actor system

Some see a system as a group of purposeful actors:

·         a collection of interacting actors (active structures)

·         who choose to perform activities (behaviors)

·         to meet their own aims (agreed or not).

Taking this actor-oriented perspective, some point to a group of people, or an enterprise like IBM, and call it a system.

They may point also to aims given to or agreed by that group.

They call the group a system, with little or no reference to the activities they perform.
The roles of the actors, they activities they perform are fluid, not under change control.


True, much activity in an enterprise like IBM is fluid.

Much/most of the enterprise is chance, human opinions, ad hoc decisions and actions.
Management involves motivating people to use their abilities and ingenuity.
Also, managing human contrariness, laziness and fraud.
But EA is not sociology, HR or business management.
Any more than it is executive level business strategy and planning.


Activity systems

Others see a system as a set of regular and repeatable activities:

·         a collection of interrelated activities (behaviors)

·         performed by role-playing actors (active structures)

·         on artefacts that are inputs, outputs or persistent system state (passive structures)

·         to meet the agreed aims of the system.

Taking perspective, an enterprise is an architected system only in so far as it realises described roles and rules.

Moreover, it is as many systems as it realises system descriptions.


EA is about human and computer activity systems in which the roles of the actors are defined.

It starts with the politics of sponsors and stakeholders.

It has to reconcile their differing world views, aims, concerns.

It progresses from discussions, to sketches to more formal specifications.

It proceeds to govern system implementations against those specifications

And then to govern change requests against those specifications.

EA is about human and computer activity systems.
Systems that are architected, tested and placed under change control.
An enterprise is only an architected system in so far as it realises architectural models.
An enterprise is a not a system per se.
It is as many systems as it realises system descriptions.

System description in general

General system theorists view a system as an island of orderly behavior in the ever-unfolding process that is universe.

In 1956, Ashby emphasised that the scope of a system is determined by its describers (read Ashby’s ideas for detail).

Given some aims or interests, Ashby viewed a system as:

·         Regular behaviors <performed by> a structural entity or interacting entities.


In 1971, Russell Ackoff listed features that he believed typified systems, as in this paper: Ackoff’s ideas.

His view might be briefly characterised as:

·         System aims <are met by> behaviors <performed by> purposeful human actors.


In the 1980s, John Zachman proposed business systems should be described by answering six fundamental questions: what, how, who, where, when and why.


Today, TOGAF says:

“Architecture descriptions are formal descriptions of a system.” (TOGAF 9.1)

TOGAF general pattern for system description may be distilled as:

·         Required behaviors (services) <are assigned to> logical structures <are realised by> physical structures.


The ArchiMate standard says the modelling language accommodates several system description concepts.

“[First,] the external view depicts what the system has to do for its environment, while the internal view depicts how it does this.

Second, the distinction between behavior and active structure.”

·         Behaviors” are processes and services performed by structural elements.

·         “Active structures” are actors and components that exhibit behaviors.

·         “Passive structures” are objects on which behaviors are performed.


This table maps those ArchiMate system element types to Zachman’s six questions.


A system description template


System element type



Usually, a name along with a generation/version number


Aims or purposes

Ideally, Simple, Measurable, Actionable, Realistic and Timebound (SMART)



Processes, interactions and services (which run from start to end) performed by active structures


Active structures

Structures (which can be found somewhere) that perform behaviors


Passive structures

Structures (which can be found somewhere) that are acted on by behaviors



Addressable locations in space where structures can be found



Moments and durations when behaviors happen


When those six questions first appeared in human language, the actors of interest were mostly human – and answers to the question: Who?

Today, a theory for business system description must also include actors that are machines and computers.

Before we say more about systems, a thorough understanding of system theory starts with an understanding of description theory.

The philosophy underlying system description

Generally speaking, one description can be realised in many realities.

And one reality can be idealised in many descriptions.

But there is more to the relationship of description to reality than that.


The premise here is that before life, there was no description.

A Darwinian explanation of description starts before mathematics, and even before words.

It starts from the notion that organisms evolved to recognise family resemblances between things.

Later, animals evolved to share their private mental models through social communication.

And in communicating with each other, they must necessarily typify the things they describe.

Read Description for a story that leads from fuzzy recognition of family resemblances to the more formal creation and use of “types”.


Philosophers have looked at description and reality in many ways – both overlapping and contrary.

Many people’s instinct is to divide the universe into mental and physical worlds.

However, the two-way mental/physical dichotomy of Cartesian dualism (after Descartes) has long been rejected by philosophers and scientists.

First, one has to shake off:

·         the mental/physical dichotomy presumed in Cartesian Dualism

·         a human-centric view of the universe

·         a language-centric view of philosophy.


Then acknowledge that:

·         describers are actors who have some intelligence about their environment

·         the ability of actors to describe the world is a side effect of biological evolution

·         the first description was a biological model of some kind, and brains evolved to retain descriptive mental models of perceptions

·         in natural intelligence, the mental world is physical – though the bio-chemistry of that is deeply mysterious

·         in artificial intelligence, the most notable ability is the ability to abstract descriptive types from observations of similar things.


And finally, acknowledge that:

·         descriptions include all signs, all models, all encodings of perceptions, private and public

·         mental, spoken, written, audio, visual and physical models are all descriptions

·         humans and their machines can translate a description of any kind into a description of another kind

·         describers and descriptions are themselves part of reality - and can themselves be described (if need be).


The philosophy here can be expressed in a triangle.

Description theory

Descriptions (private & public)

<create and use>                   <idealise>

Describers     <observe & envisage>     Realities


Intelligent describers create descriptions as a result of observing or envisaging realities.

Their observations start in sensory perceptions; their envisagings start in either dream-like or consciously-directed mental activity

Both observations and envisagings lead to the same result - the creation of private descriptive/mental models.


All social systems depend on actors translating descriptions from private memories into public messages, and back again.

Business systems can be seen as formalised social systems, in which the contents of memories and messages are defined as business data types.

The semantics of system description (after UML)

“The objective of UML is to provide system architects [and others] with tools for [modelling] software-based systems… business and similar processes.”

This section explains the semantics of system description in much the same way as the Unified Modelling Language (UML 2.5) does.

It paraphrases section 6.3 of the UML standard using words drawn from ArchiMate, TOGAF and the Zachman Framework.

Abstraction of a system from reality

Material things are always complete, infinite in their detail, and concrete.

Descriptions of those things are always incomplete, and may be imprecise, wrong, or self-contradictory.


The scope of a system is subjective; it is determined by its describers.

A system description abstracts from the infinite potentially describable details of any perceived or conceived concrete system realisation.

It is written with given aims(s) and/or concern(s) in mind.


Describers describe a system by typifying discrete behaviors and structures.

They may do this from observations of an existing system - by analysing its behaviors and structure types.

Or from envisioning – by designing or specifying how a new system is to behave and be built.


System description theory

Abstract system descriptions

<create and use>                               <idealise>

System describers    <observe & envisage> Concrete system realities


System description element types may be classified into four groups using ArchiMate terms.

The first three of these concepts appear in both UML and ArchiMate; the last appears in ArchiMate only.





occurrences in a set of similar occurrences.


performances in a set of similar performances.

Active structures

actors/objects/components in a set that perform similar behaviors.

Passive structures

objects in a set of similar objects that are acted on.


Like most practical system description methods, UML assumes behaviors are driven in discrete steps by discrete events.

However, the intervals between events can be small enough to enable the simulation of continuous behaviors.

Instantiation of an abstract system in reality

Each element type in a system description may be instantiated by many things in a concrete system realisation, or several of them.

UML names instantiations differently from their types thus.







One event that triggers a performance



One performance of a behavior, triggered by one occurrence; may generate others and change object states.

Active structure


One actor, object or component with a current state that can perform actions

Passive structure


One set of values for the variables or properties of a structural type (be it active or passive).


System descriptions do not contain concrete things: objects, occurrences or performances.

But they do sometimes name or describe such things (e.g. name the actor that plays a role).


As above, this section paraphrases the semantics of system description defined in UML.


Structural (static) semantics

Structural types include actors, components and interfaces.

Note that “actors” in UML correspond to “roles” in ArchiMate and TOGAF.

Structural types can be related in various ways, for example by dependencies.

Structural semantics also cover data types (aka variables) stored in memory spaces and exchanged in messages.


Operations or Services

Note that “operations” in UML correspond to “services” in ArchiMate and TOGAF.

Service are behaviors that can be requested from systems, or components within them.

A service is definable in a service contract, typically structured in the three sections shown below.


A service contract template


Name, input and output types.


Pre-conditions and post conditions on the state of the system before and after the service.

Non-functional measures

Duration, volume, availability, price etc.


The logic of service definition is this:

·         IF the service is invoked with inputs of the given types, and preconditions of the service hold in the initial system state,

·         AND the invoked behavior of the service completes,

·         THEN the service will produce outputs of the given types and the postconditions will hold in the resulting system state.


This logic applies equally to business systems and software systems

The behavior required of a service may be further detailed in terms of processes to be performed.


Behavioral (dynamic) semantics

Behaviors typify how things change over time.

The atomic units of behavior, the finest-grained activities, are called actions in UML.

You can think of them as executable instructions in a programming language, or the smallest steps in a human procedure.

Higher-level behavior descriptions (process flows, state machines and interactions) organise actions into logical sequences.

All behavior descriptions can be encapsulated behind service contracts, regardless of internal actions.

Behavioral semantics also cover communication by messages or information flows between senders and receivers, and the creation and use of objects.

Ten things to know about systems

There is much similarity between accounts of systems by Ackoff, ArchiMate, Ashby, TOGAF, UML and Zachman.

This paper has drawn some generalisations using terms familiar to ArchiMate users.


Nevertheless, systems thinking discussions often reveal misconceptions about systems.

And it is tempting to draw false correspondences between different disciplines.

This last section outlines some concepts, questions and issues that lead to confusion in systems thinking.


-1- System boundaries are subjective

A system’s boundary is not objective, it is determined by its describer.

 “Different observers of the same phenomena [reality] may conceptualise them into different systems and environments.” Ackoff

“The elements that form the environment… may become conceptualised as systems when they become the focus of attention.” Ackoff


A system can be both divided into component subsystems and seen as one component of a larger system.

Which is to say, a system may be seen as a holon - simultaneously a whole and a part.

The systems we observe and envisage can be discrete, integrated, overlapping or nested, one within another.


-2- Abstract and concrete systems must be distinguished

The term system is overloaded, used with several meanings.

People confuse abstract system descriptions with concrete system realisations.

The relationship is many-to-many.

One system description can be realised by many concrete entities.

One concrete entity can realise many system descriptions.


-3- The primacy of behavior over structure

General system theory focuses on system behaviors ahead of system structures.

“The principal heuristic innovation of the systems approach is what may be called ‘reduction to dynamics’ as contrasted with ‘reduction to components’ ” Laszlo and Krippner.

Ashby said a system is described in terms of one or more regular, repeated or repeatable behaviors.

So, if you cannot identify such a behavior in an entity of interest, you cannot call it a system.


Some systems thinkers assume any structure divisible into related parts can be called a system. 

Often, the entity of interest is a social group or business, and people are seen as system parts.

But what makes that entity describable as a system is its behaviors rather than its actors.


-4- A concrete entity is infinitely more than any system it realises

A concrete entity is only a system where and in so far as it realises the properties of a given system description.

“At this point we must be clear about how a "system" is to be defined.

Our first impulse is to point at [a concrete entity] and to say "the system is that thing there".

This method, however, has a fundamental disadvantage: every material object contains no less than an infinity of variables and therefore of possible systems.

Any suggestion that we should study "all" the facts is unrealistic, and actually the attempt is never made.

What is necessary is that we should pick out and study the facts that are relevant to some main interest that is already given.” Ashby 1956


-5- Social entities are one thing, social systems are another

As Ross Ashby and Russell Ackoff agreed, one entity of interest can be described as any number of systems – or as none.

In other words, a group of people doing things is not necessarily a system.

And we can usefully distinguish three concepts

·         A social entity: an entity in which people interact.

·         A purposeful social entity: a social entity in which people cooperate to reach some agreed aims.

·         A social system: a purposeful social entity in which people play describable roles in describable behaviors.


In the term Human Activity System (HAS), the A stands for Activity - a general system theory concept.
But the H makes it a specific rather than general kind of system.

The trouble is, many social “systems thinkers” conflate the two concepts.

·         A social system - a set of activities, roles and rules.

·         A social entity – a set of human actors who interact (perhaps to reach some agreed aims).


Again, the relationship is many to many.

1 social system may be realised by N discrete social entities.

1 social entity may realise N social systems (perhaps including a meta system that can change the roles and rules of another system it realises).


-6- Properties emerge from interacting systems

A mechanical system (e.g. a motor car) is composed from subsystems that interact to do things they cannot do alone.

A biological system (e.g. a human) is composed from subsystems that interact to do things they cannot do alone.

A software system (e.g. a word processor) is composed from subsystems that interact to do things they cannot do alone.


The idea that the wider or higher system has “emergent properties” is obvious to a mechanic, biologist or software engineer.

It goes without saying that the wider system can do things subsystems cannot.

Curiously, the idea of “emergent properties” has taken on a near mystical status on social systems thinking.

Perhaps because the properties of a social entity are always infinitely more than of any social system it realises?


-7- A shared language may be abstracted from domain-specific languages

Much “systems thinking” is exclusively about social systems in which actors interact by exchanging information.

And about viewing business systems as formalised social systems.

Interacting actors in a social system (a bounded context) must share the language they use in messages exchanged.

However, the actors may have their own private language, known only to themselves.

Likewise, interacting systems must share the language they use in messages exchanged.

However, the actors within those systems may have their own domain-specific language, most of which is never exposed to any other system.


-8- A “system of systems” is built from the bottom up

To a system designer, joining two subsystems for a task is so obvious it goes without saying.

If one subsystem could do the task on its own, the other would be redundant.


Business system thinkers approach the idea of system integration from various angles, using various terms.

TOGAF says: “Enterprise architecture regards the enterprise as a system, or system of systems”.

It turns out that people extract contradictory ideas from that sentence.


Systems of systems as task-specific

SEBoK defines a “system of systems” as one that integrates two or more subsystems to perform a defined behavior.

“A system of systems brings together a set of systems for a task that none of the systems can accomplish on its own.


By the definition above, one named enterprise is not one system of systems.

Consider an enterprise that uses three systems (A, B and C) to perform three tasks (X, Y and Z).

The system of systems for task X joins some subsystems of A and of B.

The system of systems for task Y joins different subsystems of A and of B.

The system of systems for task Z joins different subsystems of A and of C.


So, the enterprise is not one system of systems, it is three.

Some might call prefer to call each an “interaction” or “collaboration”.


Systems of systems as loosely-coupled.

SEBoK further characterises a system of systems by saying the subsystems are independent – both operationally and managerially.

“Each constituent system keeps its own management, goals, and resources while coordinating within the SoS and adapting to meet SoS goals."


By this definition, the many systems of systems in an enterprise are not freely assembled from the bottom up (as might be assumed from the earlier definition).

The subsystem managers are not free to choose which other systems they interact with - internal or external to the company.

They are directed, constrained and monitored from the top down.


-9- The “enterprise as a system” is a top down vision

An enterprise is a social/business entity with executive/managing directors.

It contains infinite describable systems – along with much that is not describable as a system.


The directors of a business may grant a considerable degree of freedom to managers of its divisions and operational systems.

Nevertheless, directors have legal obligations to monitor and direct their operational systems to some extent.

Even the most loosely-coupled enterprise joins its systems at the higher level of accounting and reporting to stakeholders.

Like any control system (e.g. a thermostat), the top-level management system is less than the sum of the operational systems it monitors.


The “higher” management and “lower” operational systems must exchange information.

The management system gathers selected data from operational systems, and strives to direct them by cascading aims and directives.

This implies that higher and lower systems must share a management information language (perhaps staring with turnover, profit, loss, etc.)

But (as point 7 above suggested) that shared language is likely more limited than the domain-specific languages used in each operational system.


So, in most enterprises, operational systems are not independent managerially, since there is top-down monitor and direction feedback loop.

Often, they are not independent operationally, since they were designed from the outset to interact in end-to-end value streams.

And their managers are not free to choose which other systems they interact with.

Which is to say the “enterprise as a system” concept is different from the “system of systems” concept as defined in SEBoK.


-10- Different kinds of system, different kinds of system management

Actors and behaviors are very different in different domains of discourse.

And consequently the management of those systems is also very different.


A computer activity system (CAS)

The planets in our solar system perform their orbits with no aims or management.

Arguably, the cells in our body sustain themselves with no aims or management.

A CAS does need some management.

Computer actors can do nothing but (perfectly) perform procedures given to them.

Computers do not need to be told what the business aims are, to be educated or motivated.

But managers must ensure each computer has the resources (power, memory and electricity) to do its job, and monitor to detect failure events


A human activity systems (HAS)

A HAS is very special and very peculiar kind of system, due the nature-given abilities of the actors employed.

Here are few HAS-specific terms.

Enterprise: usually implies a business led by executive managers/directors, or a segment thereof.

Organization: generally, a structure in which elements are related; in HAS, a structure in which human roles of enterprise are related; it usually implies lines of command and control.

Management system: generally, a system that monitors and directs an entity; in HAS, one that monitors and directs the operational systems of an enterprise.

Team: generally, a group of actors who interact; sometimes a node in an organisation structure; sometimes a group dedicated to the completion of a behaviour (a project or task).


Social systems thinkers are much concerned with the management of people employed in a HAS.

The elementary actions in the human procedures of a HAS may be performable by people with no further instruction.

However, people may misinterpret actions or not be well enough educated or motivated to perform them properly.

So, managers of a HAS have to monitor and direct the performance of human activities.

They have to ensure people are informed of business aims, educated and motivated to perform behaviors.

They also look to capitalise on the fact that human actors in a social entity can do much more than play roles in described social systems.


Humans and computer activity systems (HACAS)

Much "systems thinking" is about the management of human social entity or endeavour

Topics include: strategy, aims/targets, directives/principles, organisation/management structure designs, decision making, human nature/relationships/motivations, knowledge management, organisational learning, continual evolution in reaction to changes in aims or environment, disruptive forces, innovation and transformational change.

Some promote the notion of a "participatory democracy".

This is the stuff of people-centric management science rather than general (cross-science) system theory.

Sometimes, "system" is a noise word that adds little or no meaning to the discussion of an enterprise or endeavour.


By contrast, enterprise architecture is about human and activity computer systems that exhibit regular behaviors.

And about changing those systems, to optimise, replace or extend them.

The systems of interest must be stable enough to be described and managed under change control.

Further reading

This is the first of a family of related papers/chapters.

1.      The nub of our philosophy

2.      Introduction (which leads to How the brain works)

3.      A communication theory

4.      A language theory

5.      A description and type theory (which leads to Realism or Idealism?)

6.      A philosophy (which leads to Other triangular philosophies)

7.      Knowledge and truth



All free-to-read materials on the http://avancier,web site are paid for out of income from Avancier’s training courses and methods licences.

If you find them helpful, please spread the word and link to the site in whichever social media you use.