System ideas and their relevance to EA

Copyright Graham Berrisford 2014. Last updated 09/02/2019 12:27

One of a hundred papers on the System Theory page at

Find that page for a link to the next System Theory for Architects Tutorial in London.


You might assume it is universally agreed what a "system" is; but this is far from the case.

Among other things, Ashby pointed us to the schismatic difference between

·         an abstract social system of interest (the stickleback mating ritual, a tennis match, or a commercial business)

·         the actors in a social network (a pair of sticklebacks, tennis players, or IBM employees) who may realise not only the system of interest, but countless other, even conflicting, systems.


This paper introduces core system ideas, which are defined more formally System theory terminology.


The generality of system ideas. 1

The primacy of behavior 2

The granularity of atomic system elements. 2

Emergent (and immersent) properties. 3

Systems of systems. 4

System boundaries. 6

System state change. 7

System mutation (generation change) 8

Determinism.. 8

Specification of system state change. 9

Interactions. 9

Information. 10

Archetypes or design patterns. 14

Goal directedness. 15

Human organisation thinking. 16

Applying system theory. 16

Conclusions and remarks. 19

Footnote: two principles. 20

Principle: an entity is a system only when it realises an abstract system description. 20

Principle: realisation differs from translation. 21


Meanings of “system” (recap)

As many system theorists have told us, a system is a way of looking at the world.

In too many “systems thinking” discussions, people merely point to a named entity (say IBM) and call it a system.

With no further description, that is vacuous to the point of being meaningless.

W Ross Ashby urged us to recognise that by looking at IBM in different ways you can find infinite different (even conflicting) systems.


At its most vacuous and least useful, the term “system” means only "a set of things that are related to each other”.

And sometimes the relationship is very tenuous, because those things are related only by their relationship to something else.

E.g. the employees of IBM are regarded as a system purely because they are all employed by IBM.

In his introduction to cybernetics (1956) Ashby defined the concept of a system more purposefully.


The primacy of behavior

Ashby said the question is not so much "what is this system?" as ''what does it do?"

In his classical cybernetics, systems exhibit regular or repeatable behaviors.

Generally, the behaviors are performed by some actor(s) and modify some structure(s) or state variables.

That is the kind of system most system theorists are interested in.


The realisation of an abstract system by a concrete system

Next, we need to distinguish an abstract system from its realisation by one or more concrete systems

An abstract system contains the roles and rules that actors and their activities are supposed to adhere to. E.g. The stickleback mating ritual

A concrete system contains actors playing the roles and following the rules, and their actions on objects or variables. E.g. Countless pairs of sticklebacks.

In discussion and testing of the mating ritual, no attention is paid to any individual stickleback, or its complex internal biochemistry.


A network of actors and the systems they act in

Finally, we need to distinguish a network of actors from the several concrete systems they may act in.

E.g. the network of actors that are IBM employees may act in many different systems.

Some are complex, others simple; some are adaptable, others inflexible

Some are purely social, others socio-technical; some are cooperative, others in conflict.


This table distinguish the three concepts.


Abstract social system

A set of roles and rules (the logic or laws actors follow)

Concrete social system

Actors playing the roles and acting according to the rules

Social network

Actors who inter-communicate and act as they choose


By the way, a social cell is a social network in which actors find that realising the roles and rules of a particular social system is so attractive they resist any change to it.

The generality of system ideas

In “General System theory: Foundations, Development, Applications” (1968), Ludwig von Bertalanffy wrote:

“There exist models, principles, and laws that apply to generalized systems or their subclasses, irrespective of their particular kind, the nature of their component elements.” Bertalanffy


What do systems, in different domains of knowledge, have in common?

Some say a system is "an entity that contains interrelated things" or “a whole, separable from its environment, and composed of interrelated parts”.

However, that definition applies to passive structures.

E.g. a garden fence, a telephone directory, a necklace, or the Dewey decimal system.

In fact, it applies to most if not all things in the universe you can point to and name.


The term system is overloaded with different meanings.

It can refer to a passive structure of connected things and/or an abstract system description.

Here, it usually means a concrete activity system, composed of actors interacting in the activities that characterise the system.

The primacy of behavior

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

cybernetics [asks] not  "what individual act will it produce here and now?" but "what are all the possible behaviors that it can produce ?" ” Ashby 1956


A system is an island of orderly behavior in the continuous and ever unfolding process that is the universe.

E.g. consider our solar system.

The actors are a star and several planets identified by astronomers.

The activities are planetary orbits that can be described, and shown by testing to match that description.


The enterprise architecture perspective?

The solar system evolved into its currently stable form by accident and has no aims.

Enterprise architects are interested in activity systems that are designed by intent.

The system is describable in terms of roles for concrete actors and rules for their activities.

System actors are structures or components that exist in space and interact by performing the activities expected of their roles.

System activities are behaviors that happen over time, and change the state of the system or something in its environment.

The granularity of atomic system elements

The breadth or scope of a system is a choice made by system describers.

Within that scope, describers choose how far to subdivide the system by decomposition or specialisation.

They subdivide both actors and activities down to the level of atomic elements.



Atomic actors

Atomic behaviors

The solar system

sun and planets


A human body


organic processes

A beehive


deliver pollen, perform and observe wiggle dances

A predator-prey system

wolves and sheep

eat sheep, eat grass

A symphony performance

orchestra players

musical notes

A human activity system


one time, one place steps in work procedures

A computer program




An atomic actor may be a complex entity, and may play roles in more than one system.

The enterprise architecture perspective?

Enterprise architects might define a business as a system at a very high level of abstraction.

E.g. divide the Armed Forces into atomic actors called the Navy, Army and Air Force, and define a few regular interactions between them.

The very highest level business system descriptions tend to be relatively simple and stable.

At the lowest levels of decomposition and specialisation, a business may be relatively complex and change weekly or even daily.

Whatever level an architect works at, they choose what is “atomic” to them, and typically leave the internal design of atomic elements to others.

Emergent (and immersent) properties

that a whole machine should be built of parts of given behavior is not sufficient to determine its behavior as a whole:

only when the details of coupling are added does the whole's behavior become determinate. ” Ashby 1956


Holism means considering how the parts of a whole interact.

It does not mean considering the whole in complete and excruciating detail.


Emergent properties are features of a whole that depend on parts interacting.

Emergent property: a behavior or structure of a whole that depends on interactions between its parts.

E.g. the forward motion of a cyclist on a bicycle, or the V shape of a flight of geese.


Note that emergent does not mean unwanted or unexpected.

If you had never seen a bicycle ridden before, the forward motion of bicycle and rider would be a surprise.

However, that motion was wanted and expected by the bicycle designer.

The requirements for any designed system must include emergent properties.

The term emergence is also applied to what might be called abstract phenomena.

That is, to the derivation of concepts from physical or concrete matter and energy.

E.g. the emergence of information or meaning from the reading of physical signals or symbols.

E.g. the emergence of conscious thought from electrical activity in the brain.


Much else said about emergence is questionable.

“The concept has been used to justify all sorts of nonsense.” Gerald Marsh.

Read Holism and emergent properties for more discussion.


Immersent properties

People speak of complexity (and emerging properties) appearing when you consider how parts interact in a whole.

Yet the complexity of a system depends on the level of abstraction in its description.

The coarser-grained the atomic actors and activities, the simpler the system.


Complexity can also appear when you look inside the atomic elements of a system.

The deeper you immerse yourself in how something works, the more complex it gets.

E.g. a game of noughts and crosses (tic tac toe) is a social system with very simple rules; a game of chess has somewhat more complex rules.

Far more complex than either is the biology of a human actor, or the electronics of a computer actor, playing a role in the game.

Systems of systems

With his background in biology, von Bertalanffy wrote of a concept he called organicism.

Organicism: the idea that systems are describable at multiple hierarchical levels.

A system may be decomposable into subsystems, and/or composable (with others) into larger systems.


E.g. a body is composed from organs that interact in processes to sustain the body.

An organ is composed from cells that interact in processes to sustain the organ.

A cell is composed from organelles that interact to sustain the cell, etc.

At every level, a system has cross-boundary input/output flows.


The term “organicism” implies the subsystems are integrated and cooperative.

E.g. a body includes circulatory, respiratory, digestive, excretory, nervous, endocrine, immune, muscle and reproductive systems.

Note that the division of the body into subsystems is determined by whoever describes it.

The boundary of each is determined by describers, and the boundaries may overlap.


The process complexity v communication complexity trade off

Modellers choose the level of granularity at which they model the subsystems or components of a system.

There are design trade offs: the larger and more complex the subsystem, the longer and more complex the processes it can perform.

The smaller and simpler the subsystems and processes, the more complex the communication between them.


Containers of disparate systems

Bertalanffy surely presumed all parts (subsystems) are necessary to maintain or advance the whole (system).

In biology, evolutionary pressures tend shape the form and functions of an animal so as they cooperate with minimal waste and inefficiency.


By contrast, many large businesses suffer the diseconomies of scale.

They are not so much systems of systems as containers of systems.

E.g. here is hierarchical description of IBM.


Services offered

Cloud services

Mobility services

Networking services

Resiliency services

Security services

System services

Technical support services

Business operation services:

Application development & innovation services

Business Analytics & Strategy

Big Data & Analytics Services

Cloud business services

Cognitive consulting & solutions

Digital operations services

Enterprise application & alliances


Risk & fraud services

Global process services

Finance & administration process services

Human resources & learning services

Lending solutions

Managed marketing services

Recruitment process outsourcing.


Customer domains

Business operations



Content management

Customer service & CRM


Human resources

Marketing & sales.


Technology domains


Cloud computing

Cognitive computing & AI

IT infrastructure

IT management

Mobile technology


Software development.


The divisions of a large business may not all join up efficiently and effectively.

Some may not need to be joined up; some may even be competition with each other (e.g. selling mainframes and cloud services).

That is surely not what Bertalanffy had in mind when he coined the term organicism.


The enterprise architecture perspective?

Enterprise architecture (EA) is said to view the enterprise as a system, or system of systems.

Regarding the enterprise as a system does indeed explain what EA strives for.

What EA finds in practice is rather more like a container of countless systems, which are overlapping, duplicative, disparate or even antagonistic.

EA strives to de-duplicate, standardise and coordinate systems where it can.

But even in the long term, integrating systems into one coherent activity system is probably impossible.

Not least because there are naturally distinct "bounded contexts" and "domain-specific languages" in a large business.

System boundaries

“Closed and Open Systems: Every living organism is essentially an open system. It maintains itself in a continuous inflow and outflow…” Bertalanffy.


System environment: the world outside the system of interest.

System boundary: a line (physical or logical) that separates a system from its environment

System interface: a description of inputs and outputs that cross the system boundary.


If you expand the system boundary then external events become internal events, passing between subsystems.

If you contract the system boundary then internal events become external events, crossing that boundary.


Systems as “transformations”

Ashby and Checkland spoke of systems as input-to-output transformations.

Consider a factory that contains people and machines that interact in processes to achieve business goals.

It can be seen as “black box” whose primary function is to consume input supplies and deliver output products.

Inside the factory, actors act to transform the inputs into outputs in a regular and repeatable way.


The entity is orderly can well be called a system, if only at an abstract level.

However, while the general roles and processes of the system continue, individual actors come and go

Much of what particular actors do on particular days is ad hoc and lies outside of any defined role.

Moreover, the human actors must be motivated to do whatever they do.

As discussed later, not everything that happens in a human organisation can be captured in a system description.


The enterprise architecture perspective?

Remember the list of IBM’s services above?

SIPOC is an acronym that captures ideas used in business analysis, design, process and quality improvement.

The conventional business system design process defines the system-environment boundary thus:

1 Customers - entities in the environment that need outputs to meet their goals

2 Outputs – products and services customers need from the system

3 Inputs – the system needs to produce the outputs

4 Suppliers - entities in the environment that will supply the inputs

5 Processes - to produce the outputs from the inputs.


To which one might add:

6 Roles - actors play in process steps

7 Actors – hired or made to play the roles

8 Organisation – deployment, motivation and management of actors to perform the processes.


An enterprise architecture function tends to focuses on steps 1 to 6

Some social systems thinkers speak mostly to the business management concerns in steps 7 and 8.

Of course, the system design steps are entangled and iterative in practice.

System state change

“Systems concepts include: system-environment boundary, input, output, process, state….”   Principia Cybernetica


System state: the current structure or variables of a system, which may change over time.

A concrete system’s property values realise property types or variables in its abstract system description.



System state variables

Abstract description of system state

Property types (air temperature, displayed colour)

Concrete realization of system state

Property values (air temperature is 80 degrees, displayed colour is red)


The dynamics of a system are how its state changes over time.


Homeostatic v progressive state change

Actors may act to maintain a system’s state homeostatically.

This means maintaining the system in a stable or viable state, through input/output feedback loops.

Alternatively, actors may act to advance the state progressively, as in most information systems.


Continuous (analogue) v discrete (digital) state change

Analogue signals, such as a clock with revolving hands vary continuously.

And a system’s state, such as the position of a planet in its orbit, may change continuously.

By contrast, digital signals, such as a time displayed as numbers, advance in discrete steps.

And the state of an event-driven system advances incrementally in response to discrete events.


The system’s behavior in response to each event may be predictable.

However, the long-term outcomes of processing many events are not.

The trajectory of state changes over time may be unpredictably non-linear or chaotic.


The enterprise architecture perspective?

Most business systems depend on event-driven processes that run from start to end.

Every business process (short or long) is designed to produce a result or output of value to some party.

System architects model such systems using languages like UML, ArchiMate or BPMN.


A business must monitor and direct the state of the entities and processes it cares about.

And so, it runs in a feedback loop with its environment.

It receives an input event carrying new information about business entities and processes.

It refers to information holding the last-recorded state of those entities and processes.

Depending on the state, it “chooses” what actions to take.

It may update the recorded information and/or send messages to direct entities and processes

System mutation (generation change)

It is important to distinguish system state change (within a generation) from system mutation between system generations.

Like every other discrete entity, an activity system has a discrete life time, which can be long or short.

“The word "change" ... can refer to two very different things... change from state to state... change from transformation to transformation.

The distinction is fundamental and must on no account be slighted.” Ashby 1956


Three change principles:

1) The state of an activity system may change.

2) The roles and rules of a system are fixed for a system generation.

3) Changing the roles or rules makes a new system version, or a new system.


The enterprise architecture perspective?

Modern businesses depend on activity systems that are changed under change control.

Enterprise architects are concerned with the design and planning of changes to those systems from a baseline state to a target state.


“Cybernetics deals with all forms of behavior in so far as they are regular, or determinate, or reproducible.” Ashby 1956

Ashby wrote that the notion of a deterministic system was already more than century old.

Sociologists, biologists, psychologists and control system engineers all describe deterministic systems.


Deterministic: the quality of a system that means its next state is predictable from its current state and input event.

A deterministic system, in a given state, will respond to a specific stimulus or event by acting in a predictable way.





In response to inputs

And the current state of



act appropriately

electro/chemical inputs

their current electro/chemical content

Control systems


direct controlled devices

messages received

controlled devices or environment variables

Discrete event models


change state


the attributes of entities

System dynamics


increase or decrease

inter stock flows

stock quantities or population volumes



act and communicate

messages received

their memories or “mental images”  (Boulding 1956).


Paradoxically, as a result of processing a series of events, a system’s state may change in an unpredictable, chaotic or non-linear fashion.

Read Determinism and hysteresis for more.


The enterprise architecture perspective?

Enterprise architects are concerned with deterministic business systems.

Specification of system state change

Hoare logic (see the earlier paper) describes how performing a process changes the state of a system.

It is based on the Hoare triple, which may be expressed as: {Precondition} Process {Post condition}.

The meaning of the triple is: IF the precondition is true AND the process proceeds to completion THEN the post condition will be true.


Hoare logic underpins formal methods, in which the pre and post conditions are assertions or formulae in predicate logic.

But it also underpins all informal methods for analysis of requirements and ways to declare what a business process does.


The enterprise architecture perspective?

Enterprise architects specify behaviours (“value streams”, “business scenarios”, “service contracts”) in business systems.

The post condition of a business process is a requirement; a result, goal or outcome of value to the business (be it on a micro or macro scale).


The actors in a system can interact by forces, matter, energy or information, the last of which is the main interest here.



Many physical, mechanical and biological systems involve an exchange of forces.

The planets in the solar system follow orbital paths dictated by gravity.

Cyclists interact with bicycles by converting forces into motion.

However, enterprise architecture is not mechanical engineering.



“By importing complex molecules high in free energy, an organism can maintain its state, avoid increasing entropy" Bertalanffy

The seconnd Law of Thermodynamics says that across the universe, the total entropy (disorder) increases with time.

But locally, an entity can use energy to prevent an increase in entropy; and this is fundamental in thermodynamic systems.

E.g. a plant interacts with the sun by using its energy to build and maintain biomass.

Any organised entity must draw energy from its environment to maintain order and hold chaos at bay.

“In this discussion, questions of energy play almost no part; the energy is simply taken for granted.” Ashby.


Matter / materials

Animals interact with plants by exchanging gases, oxygen and carbon dioxide.

Organisms build and maintain their bodies from primitive chemicals consumed (this is called autopoiesis)

Manufacturing and supply chain businesses transform and move materials.

However, enterprise architects are usually only interested in material flows that are associated with information flows.



The ability of actors to communicate information is an amazing side effect of biological evolution.

Senders encode meaningful information in signals; receivers decode meaningful information from signals.

The types of things recognised by animals becomes evident when we match signals to situations.

E.g. we see an animal sounds an alarm call to signal an instance of the type we call “danger”.


The enterprise architecture perspective?

Enterprise architects are concerned with business inputs and outputs that are information, or are accompanied by information.


connected with system theory is… communication.

The general notion in communication theory is that of information.” Bertalanffy

Our main interest is in social and business systems in which animate and/or computer actors exchange information.


The Oxford English Dictionary lists more than half a million words.

Consider data, information, knowledge and wisdom; also signal, symbol, description, representation, meaning and model.

Given those ten words, how many clearly distinct concepts are there?


You may have come across something called a WKID triangle, pyramid or hierarchy.

This version is compatible with the information and communication theories that follow.



The ability to respond effectively to knowledge


Information that is accurate or true enough to be useful


Meaning created or found in a structure by an actor


A structure of matter/energy in which information has been created or found


All communication utilises a structure

The medium for information storage or communication is a matter/energy structure of some kind.

To communicate, animals use sound waves (calls), smells, gestures, etc.

Humans use sound waves, written text, flags, etc.

Computers use electronic signals, radio waves, etc.


Every structure has information potential

There are infinite structures in the matter/energy of the universe.

Some equate structure with information.

Here, we say a structure has information potential to actors.

There is actual information when actors use some information potential to create or obtain a meaning.


There is information potential in the variable

There is actual information when

angle of the sun’s rays

a human reads the time from the shadow on a sundial.

a sunflower perceives the position of the sun and turns to face it

nerve impulses (electrical charges)

an actor responds by removing its hand from a hot plate

bending of a bi-metal strip

a thermostat responds by switching a heater on or off.

movements of a honey bee

honey bees dance to communicate a location of pollen.

open or closed state of an office door

actors share a vocabulary in which an open door means “you have permission to enter”.

lengths of dots and dashes (in sound, light, braille…)

actors use Morse code to communicate.

quantity in a number

an actor says 20 in reply to a request for a fact (say, the speed of a bicycle in miles per hour).


Information is meaningful to its sender and/or receiver

Senders encode meanings in data structures, and receivers decode meanings from them.

The meanings include descriptions, directions, decisions and requests for them.

Descriptions are usually divided into facts (tasty, tall, scary) about things (say, food, friends and enemies) that actors perceive as discretely identifiable.


Information has at least one sender and/or receiver

A sender (a voice crying in the wilderness) may create information in a data structure that no receiver inspects.

A receiver may find some information in a data structure that was not intentionally sent.

E.g. The sun radiates a flow of light towards a rotating earth.

A sunflower finds a direction to turn its face to optimise its energy consumption.


Different actors can find different information in the same data structure

E.g. The sun radiates a flow of light towards a rotating earth.

A sunflower finds a direction to turn its face to optimise its energy consumption.

One man reads the shadow on a sundial as describing the hour of the day.

Another concludes that the sun rotates around the earth; another that the earth spins on its axis.


E.g. the data structure in a DNA molecule may be decoded by a biological cell as instructions for making proteins.

And decoded by a human reader of the genome as carrying a gene for some life-shortening condition.

Neither actor can read and act on the data structure as the other does.


To communicate requires sharing a data structure and a language

First, the data structure of a message must be preserved (a concern of Shannon’s theory).

Second, creators and users must share a language for encoding and decoding that data structure.


Two things can go wrong.


First, the data structure is distorted between sender and receiver.

E.g. Speaker says: “Send reinforcements we are going to advance.”

Listener hears: “Send three and four pence we are going to a dance.”

The intended signal is distorted at some point between sender and receiver.

Shannon’s information theory is about preserving the integrity of a data structure.


Second, creators and users use a different a language to encode and decode a data structure.

Or the ambiguity of natural language disables communication.

E.g. Speaker says: “He fed her cat food.”

Listener 1 hears: He fed her cat – food (He fed a woman’s cat some food).

Listener 2 hears: He fed her - cat food (He fed a woman some food that was intended for cats).

Listener 3 hears: He fed - her cat foods (He somehow fed the cat food that a woman owned).


In business systems, the presumption is that things do not go wrong.

Data structures are preserved perfectly.

Senders and receivers apply the same language to writing and reading them, or perfect translations are made.


Information is a subjective view of a data structure

The information in a data structure depends on senders and/or receivers and the languages they use.

E.g. I leave my office door open.

Case 1: I do it deliberately, to signal that I am open to visitors; you read the door as saying I am open to visitors, and enter my office.

Case 2: I do it by accident, but am open to visitors anyway; you misread the door as saying I am open to visitors, and enter my office.

Case 3: I do it by accident, but am not open to visitors; you misread the door as saying I am open to visitors, and enter my office.


Any meaning created or found in a message or memory structure is information to that actor

An actor can change their mind about the information found in a message.

E.g. I say the swimming pool is warm; you hear and act on that information by diving in.

I turns out the swimming pool is cold, and you now recall the information as a lie.

What a sender considers true, a receiver may consider false, and vice versa.


Knowledge is information that is true enough to be useful.

The accuracy or truth of information is a matter of degree.

Knowledge is information that is true enough to be useful (e.g. Newton’s laws of motion).

Sometimes what we say can be tested by measurement of meaning against reality.

But all measurement has a degree of accuracy, and even Newton’s laws of motion are approximations.


Read Information and Knowledge and truth for more discussion.


Information exchange in social entities and systems

A social entity is a group of actors who exchange information.

The information can include descriptions, directions and decisions - and requests for them.

The actors act according to information in messages received and memories retained.

But not necessarily in a way that is regular, repeated or predictable.


A social system is a social entity in which actors do interact in some regular or repeatable behaviors.

The actors play certain roles and communicate certain types of information.

Think of the bees in a beehive, or the hunters in an early human hunting party.

Humans have evolved more complex legal, religious and political systems.

Some have their own “domain-specific” language for communicating information.


Sociologists debate the best design for a political system.

Centralised totalitarianism, a participatory democracy, or anarchy?


The enterprise architecture perspective?

Enterprise architects are concerned with information in business messages and memories.

Business systems evolved over millennia by formalising social systems.

The actors perform activities according to messages received and memories retained.

A business formalises actors’ roles by listing activities expected of them.

And formalises the contents of memories and messages are defined as data structures composed of business data types.


A simple business system



Place order

Send invoice

Send payment

Send receipt


In enterprise architecture, information is the meaning encoded in a data structure by its creator (human or computer actor)

And the meaning decoded from a data structure by any user (human or computer actor).

In most practical contexts, the presumption is that these are the same.

Because it is presumed that creators and users write and read the data structure using the same domain-specific language.


This table defines some concepts found in business architecture.


General system ideas

Business system ideas

Defined in terms of activities


Business goal

A testable target for the outcome(s) of business activities.


Business service

A contract defining the request for and result/outcomes of required activities.


A behavior that sequences activities.

Abstract structure


A group of services offered and/or activities performable by an actor.

Business function

A group of services offered and/or activities performable by an organisation.

Concrete structure


A person (or machine?) who realises a role by performing activities in processes.


A managed unit that realises a function’s services by performing activities in processes.


Business architects debate the best design for a business organisation.

A top-down management hierarchy, distribution of responsibility to local managers, or to individuals?


The “Information Age” began when humans started using software to digitise the messages and memories of business systems.

Compare the concepts one finds in software architecture with the concepts of business architecture.


General system ideas

Application system ideas

Defined in terms of software activities


Application requirement

A testable target for the outcome(s) of application activities.

Behavior (use case)

Application service

A contract defining the request for and result/outcomes of required activities.

Application process

A behavior that sequences activities.

Abstract structure

Application interface

A group of services offered and performable by an application component.

Concrete structure

Application component

A deployable unit that realises an interface’s services by performing activities in processes.


Software architects debate the best way to control processes: centralised orchestration of components, or distributed choreography between components?

Archetypes or design patterns

There are many patterns for the design of systems.

There are, for example, patterns for communication between message senders and receivers.


Communication pattern



Point to point

Sender knows the Receiver’s address and talks directly to Receiver

Look up

Passive directory

Sender looks up the address then finds and talks directly to Receiver

Direct broker

Active directory

Sender requests the address then finds and talks directly to Receiver


Indirect broker

Message broker

Sender requests a broker to convey a message to a named Receiver

Publish subscribe

Active mediator

Sender requests a publisher to convey a message to all interested Receivers

Shared data space

Passive mediator

Sender leaves a message in a structure accessible by all interested Receivers


There are also design patterns for how system interactions are organised or controlled

The table below identifies some contrasting design patterns.


Centralised organisation

Distributed organisation

in one place or component. 

between places or components.


Anarchy or Network

Hub and Spoke

Point-to-Point or Mesh



Fork or Orchestration

Chain or Choreography


The first three are structural patterns; the last is a behavioral pattern.

Shorter processes take place within components; longer processes connect and coordinate components.

A cross-component process works either by orchestrating components, or choreography between components.


The enterprise architecture perspective?

Designers choose between design patterns by trading off their pros and cons on the light of given requirements.

Goal directedness

Bertalaffy spoke of goal directedness.

Ashby presumed goals were a given.

Throughout this book it is assumed that outside considerations have already determined what is to be the goal, i.e. what are the acceptable states.

Our concern, is solely with the problem of how to achieve the goal in spite of disturbances and difficulties. ” Ashby 1956


Some systems thinkers equate the results of behaviors with their aims.

Some use the phrase “Purpose Of System Is What It Does” as a way of thinking and approaching systems.

However, to define aims in retrospect rather than in advance is to confuse aims with outcomes.


A natural system is an entity that behaves as a system before it is perceived to be a system.

Its repeated behaviors are the outcome of evolution rather than the ideas of a living entity.

E.g. The solar system behaved as a system before it was described.

It evolved without aims, but it does have outcomes – the stable orbits of the planets.

Those outcomes are not aims, they are the unintended consequences of evolution.


A designed system is an entity that behaves as a system only after it has been conceived by a living entity.

Its reproducible behaviors are a response to the interests or aims of one or more living entities.

Designed systems have aims given to them by system owners, sponsors and others.

E.g. a country’s world cup campaign can be described in terms of aims (motivations), behaviors (activities) and structures (actors and objects).


System concepts




Reach the world cup quarter finals

Target outcomes, which give an actor a reason or logic to select and perform behaviors.


Compete in world cup matches

Processes, which run over time towards a final aim.

Active structures

Players in a national football team

Nodes (related in a hierarchical or network structure) that perform activities in behaviors.

Passive structures

Pitches, footballs

Objects acted upon during behaviors.


At the end of the campaign, its outcomes can be tested against the declared aims.


The enterprise architecture perspective?

Sponsors, designers and other stakeholders in a system's design may have different aims for, and obtain different values from, the system in operation.

Their aims and value propositions may evolve between the vision and the roll out of the system.

They may change again when stakeholders see the system in operations.

EA frameworks urge you to document aims and value propositions and keep them up to date.

It is your responsibility to keep the sponsor informed of changes.

That is not to say the purpose of a system is whatever it does.

It is to say that system design proceeds iteratively, striving to ensure that aims and outcomes converge.

It does not mean aims and outcomes are synonyms.

In the end, if the sponsor's aims are not met, they may pull the plug on the system.

Human organisation thinking

What are describable as systems contribute to a human organisation’s success.

But human organisations contain and involve much that cannot be described as a system.

Socio-cultural human organisation thinking can be equally or more important.


E.g. Suppose a human organisation’s sponsor publishes aims – some target outcomes.

But it turns out the organisation’s actors go on to achieve different outcomes.

A management consultant might analyse the discrepancy by asking whether:

·         the aims were unrealistic

·         the sponsor didn’t really care about the aims

·         the sponsor hid their real aims

·         the sponsor changed their mind about their aims

·         the actors were inept

·         the actors were not aware and reminded of the aims

·         the actors were not motivated or rewarded for meeting the aims

·         the actors were encouraged (perhaps financially rewarded) to do something else

·         the actors were not discouraged by managers from doing something else

·         external forces (political, economic, social, technical, legal, etc) steered the organisation differently.


Again, human organisations contain and involve much that cannot be described as a system.

Applying system theory is not enough; other kinds of analysis (illustrated above) are necessary.


To label all such analyses as “systems thinking” is unhelpful.

And in some “systems thinking” discussion the term “system” is no more than a noise word.

By contrast, the word does have a clear and useful meaning in classical system theory and cybernetics.

It helps to explain what enterprise architecture can do, and cannot do.

Applying system theory

Remember, a system is an island of orderly behavior in the continuous and ever unfolding process that is the universe.

It is describable in terms of roles for concrete actors and rules for their activities.


For some, understanding and applying system theory requires making a paradigm shift.

A shift as radical as is needed to understand Charles Darwin’s evolution theory.

Until there is a system description, there are infinite potential systems, but no defined system.


Ackoff spoke of concrete systems (with physical elements) and abstract systems (with conceptual elements).

“Different observers of the same [concrete] phenomena may conceptualise them into different [abstract] systems.” Ackoff 1971

A concrete system behaves (near enough to satisfy the observer) as described in an abstract system.

But as Ackoff indicated, the behaviours of one concrete entity may match several different abstract systems.


Ashby put it more forcefully.

“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 [concrete entity has] 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


In effect, to apply system theory is to apply the scientific method to a description of the world.






Philosophy and maths

A type

helps people understand and describe


Scientific method

A theory

helps people understand and predict


System theory

An abstract system

helps people understand and make

concrete systems


An instance is something that exhibits (near enough to satisfy the observer) the properties of a type.

A scientific truth is what is measured (near enough to satisfy the observer) as matching what is predicted by a theory.

A concrete system behaves (near enough to satisfy the observer) as described in an abstract system description.


Applying system theory means forming abstract system description (a type or theory).

And testing that the behavior of a concrete system instantiates or realises that type.


Abstract system description

Concrete system realisation


An instance

Theoretical system

An empirical system

General roles and rules

Some particular actors and activities

“Solar system” definition

Some planets orbiting a star

Laws of tennis

A tennis match

The score of a symphony

A performance of that symphony

The US constitution

A US government


This table may help to show how these concepts are related.


Roles, performances and actors

Abstract system descriptions, concrete system realisations and concrete entities

There can be several performances of a role.

There can be several concrete realisations of an abstract system description.

An actor is infinitely more than their performance of one role.

A concrete entity is infinitely more than its realisation of one abstract system description.

An actor can perform several roles, successively or in parallel.

A concrete entity can realise several abstract system descriptions, successively or in parallel.


IBM as an example

You might hear people say IBM, or a division of it, is a system.

However, asked to define IBM as input-process-output system, one might say:

·         Inputs: oxygen. Outputs: CO2.

·         Inputs: electricity and food. Outputs: heat.

·         Inputs: money from customers and investors. Outputs: salaries and dividends.

·         Inputs: raw materials and components. Outputs: concrete products.

·         Inputs: questions and paper. Outputs: answers and documents.

·         Inputs: knowledge. Outputs: integrated or advanced knowledge.


IBM can realise several abstract system descriptions, successively or in parallel.

And IBM is infinitely more than its realisation of any one abstract system description.

So to say IBM is a system is meaningless unless you point to your chosen abstract description.



System descriptions

<create and use>                       <realised by>

System describers <observe and envisage> The behaviors of IBM


The US government as an example

A US government is infinitely more than its realisation of any abstract system description.

It is an ever changing entity in which stuff happens.


A US government can manifest, instantiate or realise several abstract system descriptions, successively or in parallel.

Different people will define the aims, inputs and outputs of the government differently, each expressing their own perspective of “the whole.”


So to say the US government is a system is meaningless unless you point to your chosen abstract description.

Indeed, every US government is testable as realising the abstract system description known as the US constitution.


US government

US constitution

<created>                        <realised by>

US founding fathers  <envisaged>       US governments


The US constitution defines the roles of the Congress (the legislative branch), the President, the court system (the judicial branch) and the States.

It also defines relations between actors playing those roles.

It does not define most of what the federal government does day to day, or the roles or rules of its subordinate institutions.

It does however also define the meta system to be used (by Congress or Constitutional Convention) to amend the constitution itself (change the system).

Conclusions and remarks

Understanding systems involves drawing three distinctions.


There are structures and behaviors – actors and activities - within a system.

What do all the systems above have in common?

They all have some regular or repeatable behavior(s), some roles and rules that can be described.

Behaviors may maintain a system in a stable state, or advance a system’s state progressively.


There are accidental and purposive - natural and designed - systems.

Which comes first? Abstract system description or concrete system realization?

A natural concrete entity (like the solar system) behaves as a system before it is recognised and described as a system.

A designed concrete entity (like a motor car or a symphony) cannot behave as a system until after it has been described, if only in a mental model.


There are descriptions and realisations - abstract and concrete systems.

People struggle to grasp this.

A system is a defined set of interrelated activities performed by actors.
The scope of the set is subjective - a choice made by a system describer.
One defined system may be realised by several concrete entities.
One concrete entity can realise several defined systems.
“Different observers of the same phenomena may conceptualise them into different systems.” Ackoff
Different observers of one business may conceptualise them into different root definitions – after Checkland
Our first impulse is to point at a thing and say "the system is that" but that thing has no less than an infinity of possible systems – after Ashby.


Here is an example of abstract and concrete systems.


An abstract or theoretical system describes roles played by actors and rules governing their activities.

E.g. A symphony score describes roles played by orchestra members (listed vertically), and rules governing their activities (scripted horizontally).


A concrete or empirical system is an entity in which actors play roles in performing described activities.

E.g. A symphony performance is an entity in which orchestra members perform the activities described in a symphony score.


An entity is only an empirical system to the extent that, verified by observation, it matches a theoretical system.

E.g. An orchestra delivers a symphony performance to the extent that, verified by observation, its actions in reality match those described a symphony score.


Actors are addressable in space, their activities are located in time.

E.g. Orchestra members are addressable in space, the sounds they make are located in time.


System activities change the state of the system (or the state of entities in the system's environment).

E.g. Playing a score advances the state of a performance (and the memories of audience members).


A theoretical system enables us to predict/measure/test state changes in an empirical system.

E.g. A symphony score enables us to predict/measure/test the progress of a symphony performance.


In short, an entity is only a system in so far as it realises an abstract system description.

The mark of a good system description is that you can test how well it is realised in real-world phenomena.


Much written by social systems thinkers (e.g. Luhmann) has little to do with systems in that meaningful and useful sense.

Their use of terms like "system", "autopoiesis" and "emergent properties" often appears pseudo-scientific.

Peter Senge explicitly promoted systems thinking as an alternative to classical system theory.

Today, some don’t acknowledge there is a schism.

Others belittle classical system theory, using terms like “engineering”, “linear” and “clockwork machine”.

Still, all modern society depends on large and complex engineered systems, which sometimes behave in magical or mysterious ways.


The enterprise architecture perspective?

EA frameworks depends on classical system theory ideas.

That does not mean human organisations are best or only viewed as machines!

Human organisation thinking has it own and different value to the success of a business.

Footnote: two principles

Principle: an entity is a system only when it realises an abstract system description

The universe is an ever changing entity in which stuff happens.

To be called a system, a concrete entity must exhibit (manifest, instantiate, realise) the properties of an abstract system.

What if it stops doing that?


When an entity stops exhibiting the behaviors of a system, the system no longer exists.

E.g. When the organs of tiger stop working, the tiger dies.

When planets fall out of their orbits, there will be no solar system.

When the players in a tennis match go home, the tennis match is over.


What remains when an activity system stops running?

An abstract system description may persist long after the concrete system has disappeared.

But what remains of the concrete system?


In some cases, the system rests in the form of a structure containing parts that can be started up again.

E.g. An airplane’s mechanical parts are dedicated to their role in flying the plane

When an airplane rests in a hangar the parts stop playing their roles.

But they remain contained within the airplane’s carcass, and may resume their roles the next day.


When a bank closes for the night, its employees stop playing roles in it.

Overnight, those employees play other roles, in families, in bars, in part time jobs as football coaches.

Those people are not “parts” of the bank system in the sense they are dedicated to the bank, or the bank “contained” them.

Rather, they are actors hired to play roles in the bank system.

The “part” they play in the system is limited to the activities expected of those roles.

Outside of that, they are participants in the bank viewed as a social entity rather than viewed as a system.

Principle: realisation differs from translation

Here, idealisation or conceptualisation means abstracting a description from a reality that is observed or envisaged.

Whereas translation means transforming one description of a reality into another description of the same reality.


Realisation = the operation of a concrete system that is testable against a system description
The US constitution is a document that conceptualises the structures and behaviors of the system that is a US government.

This public document was agreed by its authors and is understandable by all who share the authors' understanding of the words in it.

It has been realised in concrete / operational / run-time systems throughout the history of the US by successive government bodies.

Translation = transformation of one system description into another (more or less refined) description

The US constitution authors translated and collated their mental models into a documented model.
Readers of the published document translate it into their private mental models.

All documented and mental models are abstract system descriptions.

Obviously, documented models are more stable and shareable, which is why we create them.

We document models also so that we can demonstrably test the behavior of real-world systems against the models.



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.