General System Theory for enterprise architects

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 29/03/2017 22:23

 

There are two “system” traditions.

The sociological tradition can be traced back to the 19 century.

General system theory (GST) emerged after the second world war.

This paper explains some crucial differences between them and suggests a way to reconcile them.

It is a companion to another paper that distils and reviews Ackoff’s ideas about systems.

And is the basis for one session in our next tutorial: System Theory Tutorial: May 2017 in London.

Key references: Introduction to Cybernetics” (1956) W. Ross Ashby.

And “Towards a System of Systems Concepts” (1971) Russell Ackoff.

Contents

Abstract 1

FIRST HALF: ten general system theory principles. 2

General system theory and EA.. 2

Generalising from other sources. 3

Principles about encapsulation. 4

Principles about description and reality. 7

Principles about change. 10

SECOND HALF: implications of the principles above. 11

On “change”. 11

On “complexity”. 13

Differentiating social organisations from social entities. 14

Scientism/assertion versus science/testing. 15

How to reconcile SST with GST and EA.. 16

Footnotes on philosophy, science and GST. 21

 

Abstract

There are two “system” traditions.

The sociological tradition can be traced back to the 19 century.

It might be called “sociological systems thinking” (SST).

It is evident today in what some call “management science” or “organisation theory”.

 

General system theory (GST) emerged after the second world war.

It is generic, meaning cross-science, and focuses on systems of repeatable behaviors.

It is practical and widely applied in the analysis and design of deterministic activity systems:

·         software systems

·         human activity systems in which the participating actors follow defined rules in defined roles.

·         every system that has been successfully modelled using System Dynamics (after Forrester and Meadows)

·         every system defined using enterprise architecture (EA) frameworks and modelling languages.

 

Management scientists (e.g. Boulding, Ackoff and Beer) have tried to merge SST and GST.

However, only some parts of SST fit GST, the rest of SST might more accurately be called “Social Entity Thinking”.

 

The first half of this paper explains ten principles.

The second half explores some implications of these principles.

FIRST HALF: ten general system theory principles

General system theory and EA

Ludwig von Bertalanffy (1901-1972) is regarded as the founder of General Systems Theory (GST).

Some of his views of life, evolution, and the human condition are questionable.

But the six core ideas below are more widely accepted, and are reflected in modern Enterprise Architecture methods like TOGAF.

 

Holism or wholeness

Bertalanffy wanted to shift attention from the parts of a system to the whole.

“General System Theory… is a general science of wholeness… systems [are] not understandable by investigation of their respective parts in isolation.” Bertalanffy

EA takes a holistic view of a business; TOGAF “regards the enterprise as a system of systems”.

 

The primacy of behavior

Bertalanffy wanted to shift attention from static parts to how they are related in dynamic behavior, to “phenomena not resolvable into local events.”

Others have considered this to be the fundamental innovation of system theory.

TOGAF starts not from the structure of a system but from the services required of it.

And the end-to-end processes (value streams, scenarios) needed to provide those services.

 

Recursive system description

Bertalanffy promoted the idea of "organicism," that systems should be treated (like organisms) as describable at multiple hierarchical levels.

It is axiomatic that:

·         Systems can be hierarchically nested: one system can be a part or subsystem of another.

·         Systems can overlap: they can share the same part or subsystem.

·         The smallest possible system (or subsystem) encapsulates one primitive/atomic action.

·         An event that is external to a smaller system is internal to a wider system (and vice-versa).

·         The emergent properties of a small system are ordinary properties of any wider system it is a part of.

 

Systems can be recursively composed and decomposed not only in space but also in time or logic.

TOGAF recursively decomposes business functions/capabilities and processes.

 

System-environment boundary

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

“Essentially” means an organism cannot live without inputs and outputs.

It is axiomatic that systems can interact: output from one can be input to another.

TOGAF regards a business as a system that maintains itself in a continuous inflow from suppliers and outflow to customers.

 

Information flows

 connected with system theory is… communication. The general notion in communication theory is that of information.

A second central concept of the theory of communication and control is that of feedback.” Bertalanffy

TOGAF defines information flow feedback loops between businesses, customers, suppliers and employees, in terms of services requested and provided.

 

System state

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

TOGAF defines data stores that hold data entities, which record the state of business entities and activities.

 

Any brain or business can be seen as a control system connected in a feedback loop with its environment.

It receives information about the state of entities and activities in its environment.

The state information must model reality well enough, else the system will fail.

It records that state information in memory.

It outputs information to inform and direct “motors” as need be.

Generalising from other sources

Principle: The primacy of behavior

This table defines three core concepts in system description.

Terms

Example

Meaning

Aims

win the world cup

target outcomes that give an entity a reason or logic to perform and choose between actions.

Behaviors

compete in world cup matches

processes than run over time with intermediate outcomes and a final aim or ideal.

Active structures

players in a national football team

nodes, related in a hierarchy or network, that perform activities in behaviors.

 

GST is concerned with activity systems that operate in the real world, displaying behaviors of some kind.

“A set of elements or parts that is coherently organized and interconnected in a pattern or structure that produces a characteristic set of behaviors." Meadows

The systems can be characterised as having parts that interact in “regular, repeated or repeatable behaviors” W Ross Ashby.

 

A system is an entity whose processes are repeated to maintain the state of the system and/or reach another goal.

This table compares a generalised description of a system (distilled from analysis of many different sources) with two sources not used in that analysis.

General System Theory

In EA/TOGAF terms

In Donella Meadows’s terms

A bounded structure of

A bounded organisation of

A bounded and coherent organization/structure of

actors/organs that interact by playing

actors/components that interact by playing

elements/parts that interconnect dynamically by performing

roles in

roles in

*

behaviors to meet

processes to meet

behaviors to meet

goals, by maintaining

goals/objectives/requirements by maintaining

functions/purposes by exchanging

system state and exchanging

data entities and providing

*

inputs/outputs with each other and with

input/output services to each other and to

inputs/outputs with each other and with

entities outside the boundary, using

entities outside the boundary, using

entities outside the boundary.

system resources.

platform technology components.

*

 

The rows marked * are blank because System Dynamics advocate Meadows doesn’t mention roles, system state or resources in the quotes below.

 “System: A set of elements or parts that is coherently organized and interconnected in a pattern or structure that produces a characteristic set of behaviors, often classified as its function or purpose."
"Every system must exhibit these 8 characteristics in order to qualify as a system: Boundaries, Elements/Parts, Coherent Organization/Structure, Interconnections, Function or Purpose, Behavior greater than sum of parts, Inputs/Outputs, is Dynamic."

Principles about encapsulation

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

TOGAF regards a business as a system that maintains itself in a continuous inflow from suppliers and outflow to customers.

Principle: an open system interacts with its environment

The environment outside a system contains structures/entities and behaviors/events that can change the state of the system, or be changed by the system.

 

System encapsulation (IPO) as system scoping

There are usually feedback loops between a system and its environment.

To encapsulate a system means defining its input-process-output (IPO) boundary.

The inputs and outputs can be flows of information, material or energy.

 

“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

A system describer defines the inputs and outputs with reference to an already-given interest or aim.

 

Remember, the system-environment boundary is a choice made by system describer(s).

It meaningless to point to an entity and call it a system if its boundary and properties are obscure.

First, those in the discussion must agree its boundary and which I/O flows are relevant to some shared interest.

The I/O flows of interest in business system models are rarely energy flows, sometimes material flows and often information flows.

TOGAF defines a business and each application/technology component it uses by the I/O services it offers.

 

System design as a process

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

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

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

2 Design Outputs - that customers need from the system

3 Design Inputs – that the system needs to produce the outputs

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

5 Design Processes - to produce the outputs from the inputs.

 

To which one might reasonably add:

6 Define Roles - in which actors can perform the process steps

7 Hire and/or make Actors - to play the roles

8 Organise, deploy, motivate and manage the actors – to perform the processes.

 

Many sociological systems thinkers speak to the concerns at step 8.

 

Of course, the process is iterative in practice.

Systems and processes can be, and are, composed and decomposed.

Decomposition continues until individual actors can be hired or made to perform the required behaviors.

 

At every level of system composition, there are cross-boundary input/output flows.

If you expand the boundary then external events become internal events that pass between subsystems.

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

 

Aside on archetypes or design patterns

Archetypes are used in designing the structures and behaviors in which subsystems interact.

General, cross-science, archetypes appear in contrasting design patterns listed in this table.

Centralisation of control

Distribution of control

in one place or component. 

between places or components.

Hierarchy

Anarchy or Network

Hub and Spoke

Point-to-Point or Mesh

Client-Server

Peer-to-Peer

Fork or Orchestration

Chain or Choreography

 

The last of these is a behavioral rather than structural pattern.

System architects choose between alternative patterns by trading off their pros and cons on the light of given requirements.

Principle: a closed system is sealed from its environment

An open system interacts with entities and events in a wider environment.

A closed system does not interact with its environment.

 

Aside: Every “system dynamics” model is a closed system.

It is a model of populations (stocks) that grow and shrink in response to continuous inter-stock event streams (flows).

The whole system is closed, so all events are internal events.

However, each stock can be seen as a subsystem, to which every event is an external event.

 

System dynamics models represent continuous inter-stock flows as events-per-time-unit (e.g. total births per month).

When running the model to simulate a reality, the time unit is the discrete event that drives the system to change state incrementally.

The real-world events being modelled appear as units (1s) aggregated in the quantitative variables (e.g. total deaths per month).

M A Jackson (c1975) credited this insight to Mike Woodger of the National Physical Laboratory in Teddington UK c4 miles from where I sit.

Principle: systems can be composed and decomposed

Systems (along with aims, behaviors and structures) can be described at different levels.

Systems can be hierarchically nested: one system can be a part or subsystem of another.

Systems can be recursively composed and decomposed not only in space but also in time or logic.

 

So, how to describe different levels of system composition/decomposition?

Ackoff arranged aims, behaviors and systems in hierarchical structures, using different words at different levels.

It can be convenient to use different words for different levels of system concept, e.g.

 

Time-frame

Aims

Behaviors

Active structures

Granularity

Persistent

Business mission

 

Enterprise

Whole

Long term

Goal

Value stream

Division

Composite

Short term

Objective

Process

Team

Part

Immediate

Requirement

Action

Actor

Atom

 

However, the level of composition or decomposition is arbitrary – a choice made in a particular situation.

It is impossible to be scientific about pinning different words to different levels of a three, four or five level decomposition.

And trying to do so can obscure the general nature of system theory.

 

The concepts are the same at whatever level of system composition you choose to model.

A process is an event-triggered sequence of actions that may refer to system state, include choices and produce outcomes.

A choice is a choice: whether it is made by strict or fuzzy logic, deterministically or by free will (if you consider those to be incompatible).

Principles about description and reality

An entity is a system whenever and wherever it matches an abstract system description.

Principle: descriptions idealise observed or envisaged realities

This practical idealism triangle is a generalization of how the world is described.

Practical Idealism

Abstract descriptions

<create and use>              <idealise>

Describers  <observe and envisage>  Concrete realities

 

Aside: describers and descriptions are realities that can be described.

 

The triangle is specialised below to relate role definers, roles and actors who play the roles.

Bear in mind, a person may double as role definer and actor in the same business; we’ll return to that point later.

Social organization

Defined roles

<define and change>              <idealise>

Role definers <observe and envisage> Real-world actors

Principle: concrete systems realise abstract ones

A system is a set of elements that relate or interact in a structured or orderly way.

All the elements must be related directly or indirectly, else there would be two or more systems.

This definition embraces both passive structures (e.g. tables) and activity systems.

The concern of GST is activity systems, in which structural elements interact in orderly behaviors.

 

A system takes two forms: a concrete system realises (or instantiates) an abstract system description (or type).

Abstract system description

Theoretical system

System description

Concrete system realisation

An empirical system

A system in operation

 

An abstract system is a system in which the elements are concepts.

It may be purely conceptual, or describe an imagined or envisaged reality, or describe an observed reality.

Abstract system description

The Dewey Decimal System

“Solar system”

Laws of tennis

Defined roles (e.g. Orchestral parts)

The score of a symphony

 

Abstract descriptions do take concrete forms; they are found in mental, documented and physical models.

What matters here is not the form but the relationship of the description (model, conceptualisation, idealisation) to a reality that is observed or envisaged.

 

A concrete system is realization in physical matter and/or energy of an abstract system description.

Abstract system description

The Dewey Decimal System

“Solar system”

Laws of tennis

Defined roles (e.g. Orchestral parts)

The score of a symphony

Concrete system realisation

Books sorted on library shelves

Planets in orbits

A tennis match

Actors (e.g. Orchestra members)

A performance of that symphony

 

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

A designed concrete system (like a motor car) cannot run in reality until after it has been described, however abstractly.

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

Principle: an entity is a system whenever and wherever it realises an abstract system description

“Different observers of the same phenomena may conceptualise them into different systems.” Ackoff

 

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

Our first impulse is to point at [an entity displaying behaviors] 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.” Introduction to Cybernetics (1956) W. Ross Ashby

 

In other words: a substantial entity has well-nigh infinite detectable and measurable properties.

Any system description that entity conforms to can include only a tiny fraction of that entity’s describable properties.

We abstract relatively simple abstract system descriptions from infinitely complex realities.

A system is a perspective, a selective idealization of an observed or envisaged reality.

It is an island of stability imposed by a system describer in the ever-unfolding processes of the universe.

 

As Ackoff and Ashby said in their different ways.

A group of people doing things is not a system just because people call it a “system” or an “organisation”.

The US economy, a church or IBM is a not a system; it is infinite possible systems.

It is as many different systems as system describers can successfully abstract, describe and test.

 

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

Until those properties have been described and observed, the entity is an unbounded, amorphous part of the universe.

An entity is a system whenever and wherever it matches an abstract system description.

 

An entity:

·         is a thing that has continuity of identity over time

·         is a system where and in so far as it realises an abstract system description.

·         can be zero, one or many systems at once.

·         can be different systems over time (e.g. caterpillar and butterfly).

 

People find this hard to understand and accept, but here goes.

It is meaningless to say a named entity is a system until you are sure it realises a system description.

Until there is an abstract system description an entity cannot fairly be presumed to be a system.

(An exception might be made for a life form, which may be presumed to realise the system described in its DNA.)

 

A philosopher is reputed to have said: “I know there is stuff out there; I am just not quite sure what it is.”

In what sense does the stuff called the “solar system” exist?

Its boundary, the structures it contains and how they behave, were not only defined by astronomers, but have also been changed by astronomers.

Today, real-world phenomena (planets in orbits) can be observed and measured as conforming – well enough - to the system description

Gradually, those phenomena will change until they are longer recognisable as matching that description.

 

GST note: The universe, or IBM, is an ever changing entity in which stuff happens.

A concrete system is

·         an island of repeatable behaviors carved out of that universe.

·         a set of describable entities that interact in describable behaviors.

·         an entity we can test as doing what an abstract system description says.

With no system description, there is no testable system, just stuff happening.

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.

Principles about change

Principle: continuous behavior can be modelled as driven by discrete events

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

 

System properties

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 current state of a concrete system realises (gives particular values to) property types or variables in a system description.

Other qualities of that entity are not a part of that system, but might count as part of another system.

E.g. the temperature of the earth’s atmosphere is irrelevant to its role in the solar system, but vital to its role in the biosphere.

 

A system’s state may change continually, or in discrete steps

In either case, the system may be modelled in terms of discrete state changes that result from discrete events detected.

 

State change: a change to the value(s) of a system’s variable(s) in response to a discrete event.

 

An event is a discrete input or occurrence that triggers a process within a system.

It can trigger a state change, or one of several optional state changes.

 

A process is an event-triggered sequence of actions

It may refer to system state, include choices and produce state changes and/or outputs.

 

GST note: On discrete event-driven behavior.

External events cross the boundary from the environment into the system.

Within a system, internal events pass between subsystems.

In response to an event, a system refers to current system state.

It then “chooses” what actions to take, including actions that change its own state.

The choice depends on the values of input event variables and internal state variables.

Principle: system change differs from system state change

A general theory is about concepts that appear and reappear in different domains of knowledge.

Synonyms, using different words for the same concept is OK.

Homonyms, using one word for different concepts is not generalisation.

 

For example “change” can mean various things; it is important to distinguish:

·         changing state within a system generation - system adaptation

·         changing nature between system generations - system evolution.

 

GST note: On change

The current state of a system is measurable in the values of described variables.

Changing state means changing the variables’ values.

Changing a system means changing the variable types or the rules applied to them.

 

SECOND HALF: implications of the principles above

There is perhaps more tosh talked about system change and system complexity than any other topics in system thinking.

This second half of the paper starts with some observations on those topics, and moves on to other observations, suggestions and and conclusions.

On “change”

 

Change in biological systems

This table suggests there is no one definitive list of what characterises a life form.

According to this source

living entities share 8 characteristics

General System Theory

concepts

According to this source most

living entities have 7 characteristics

Heredity

system description

Adaptation through evolution

system change

Reproduction

system instantiation

Reproduction

Growth and development

system state change?

Growth

Cellular organization

system structure/composition

material input

Nutrition

Metabolism

material processing

Respiration

material output

Excretion

information input

Sensitivity

Response to stimuli

information processing

Movement

Homeostasis

information processing

 

It is curious that nobody mentions decay and death (or taxes) as characteristics that define a living entity.

From a GST perspective, these characteristics are interesting:

·         Sensitivity to stimuli - the entity can detect changes in the state of its environment.

·         Response to stimuli – the entity responds to events, typically by triggering some motor actions.

·         Homeostasis – the entity responds to internal and external state changes so as to maintain system state.

·         Reproduction – the entity creates a new generation, a new version, of the system.

 

At least six kinds of system change can be distinguished in animal entities.

·         Growth by maturation – we develop from egg to adult.

·         Decay by ageing – if we didn't reproduce and then die, our species could not evolve.

·         Evolution by reproduction - we pair off to produce a new, different, member of our species (system generation N + 1).

·         Autopoiesis – our cells sustain/replicate their own complex chemistry from primitive chemical inputs.

·         Homeostatic adaptation - our body responds to internal and external state changes so as to maintain its state variables in acceptable ranges.

·         Learning by conditioning - a mind/body remembers past inputs and responds to new inputs according to past experience (implies pattern recognition and fuzzy logic).

 

Some system thinkers use the terms above when discussing social entities (e.g. autopoietic social systems and organisational learning)

But applying the same terms to very different phenomena is to develop a special system theory rather than a general one.

 

Evolution in biological systems

In the special case of a biology entity, there are many possible abstract system descriptions.

It may be argued that an organism’s DNA is the most fundamental description of an organism.

Incrementally, generation by generation, biological evolution changes the DNA of an organic system.

 

Evolution in designed systems

In the special case of a designed system, there must be at least one abstract system description (be it a mental or document model).

Incrementally, generation by generation, changes to a system description can be realised in designed system.

With no system description, there is no design, and no way to plan design and build effort.

 

EA languages like ArchiMate are used to describe and design business systems.

Enterprise architects analyse a baseline system and design a target system.

They then plan and govern the transition from the baseline system (version N) to target system (version N+1).

They presume changes to concrete systems are governed (under change control) against documented system descriptions.

 

On “complexity”

 

Increasing complexity

Incrementally, generation by generation, biological evolution can increase organic system complexity.

Incrementally, generation by generation, design effort can increase a designed system’s complexity.

The complexity of a system can only be measured by counting elements that appear in a description of the system.

 

Outside of biology and designed systems, people often refer to a complex reality as a complex system.

But not every reality has the properties generally ascribed to a system, or can be described as a system.

And with no system description, there is nothing a complexity measure could be applied to.

 

Social entities versus social systems

Again, general system theory is about concepts that span different domains of knowledge.

It is not about using the same words to mean different things.

Specific domains of knowledge have their own specific terms and specific system theories.

 

E.g. Maturana and Varela characterised living entities as autopoietic.

This means self-sustaining; an autopoietic organism manufactures its own body parts from primitive edible chemicals.

In sociology, the term self-organising means something very different.

It means people changing the aims, variables or rules of the business they work in.

.

Ackoff and other systems thinkers speak of social groups that continually change their aims and behaviors.

Systems in which "parts" can choose by "free will" how they respond to inputs, and change the goals of the system, are special systems.

They are not systems in the GST sense of the term system (or any normal sense of that term).

 

Where systems thinkers refer to a “complex adaptive system”, a general system theorist might refer to a “complex evolving entity”.

This table classifies change types - using the word purposeful to imply choices are made by free will.

Continuous change

Discrete step change

Not purposeful

Natural physical system

Biological homeostatic adaptation

Biological reproduction

Purposeful

Self-organising social entity

Designed system

Enterprise architecture

 

Differentiating social organisations from social entities

One of Russell Ackoff’s most profound insights in 1971 was this:

“Different observers of the same phenomena [usually, people doing stuff] may conceptualise them into different systems” or indeed, into no system at all.

In other words, an entity is a system whenever and wherever it realises an abstract system description

 

Later, Ackoff contradicted himself by presuming a church, a corporation or a government agency is a “system” regardless of any conceptualisation.

The problem with much SST is this presumption: that all actors employed by an employer (along with everything they touch and do) necessarily form one "system".

 

A group of people doing things is not a system just because people call it a “system” or an “organisation”.

The US economy, a church or IBM is a not a system; it is infinite possible systems.

It is as many different systems as system describers can successfully describe and test.

And some of those systems may conflict with each other, or undermine each other.

With no system description, to assert IBM is a system conveys no meaning beyond saying it exists.

 

What realises a defined role (in a system) is not an actor, it is an actor’s performance of the actions expected in that role.

What an actor does outside their defined system role is not a part of that system, but might be part of another defined system.

E.g. a person’s singing is irrelevant to their role in a tennis club, but vital to their role in a choir.

 

In GST terms, the parts of a social organization (business or government) are assignments of actors to roles, not the actors themselves.

 

Social organization

Abstract system description

Roles

Concrete system realization

Assignments of actors to roles

 

Systems thinkers blur the concepts of social entity and social organization, but they can be differentiated more in line with GST.

The key is to recognise that human actors give a fraction of their time, energy and abilities to each system role they are assigned to.

 

A social entity is a collection of physical actors who communicate with each other.

One social entity can act as several social organizations – its actors can play unrelated roles in (say) a tennis club and a choir.

A social organization (say a tennis club, or choir) is a set of logical roles, which need actors to play them.

One social organization can be realised by several social entities. All the actors who play its roles can be replaced.

Scientism/assertion versus science/testing

Scientism is the practice of asserting things to be true in a way that sounds like a scientific statement.

E.g. “Organic foods are better for you”.

Science is more; it is the practice of testing assertions in an attempt to confirm or deny them.

Scientists need a well-defined scientific vocabulary both to communicate effectively and to produce testable system descriptions.

At a fundamental level, scientific language helps shape thinking and provides the means for constructing new theories and test cases.

 

General System Theory and science

GST helps us to produce an abstract system description (a theory) against which a concrete system realisation can be tested empirically.

Usually (not always) the system description is verbal, and is defined using a domain-specific language.

E.g. The US constitution describes a system of a government against which the structures and behaviors of real-world US governments have ever since been tested.

 

GST note: On system testing

A system can be tested, as any other scientific theory can be tested.

The system is a collection of repeated or repeatable behaviors whose progress can be measured in terms of changes to variables.

1.      You observe or envisage a discrete concrete entity.

2.      You hypothesise that the entity can be observed or built to realise (near enough) an abstract system description.

3.      You describe the system (in a mental or documented model) by defining the abstract property types/variables and rules you envision will be measurable.

4.      If the entity does not exist, then you manufacture it.

5.      You set the entity in motion and test it gives values to the defined variables (near enough) as you expect.

 

System Dynamics and science

A System Dynamics model is an abstract system description (a theory).

Running the System Dynamics model is sometimes presumed to be a test of the theory, but it isn't; it is only an animation of the theory.

System testing requires that the results of running the model are compared with the result of whatever reality is modelled.

 

Sociological System Thinking and science

Sadly, in much SST discussion there is a real-world entity, but no system description against which reality can be tested (or else testing is impossible).

In which case, calling the entity or organisation a "system" is an empty assertion; the word "system" is a meaningless label.

 

Some systems thinkers speak of continually evolving systems.

The idea being that actors can continually change the aims, variables, rules and roles of a system they act in.

If there is no change control from one discrete system generation or version to the next.

Then there can be no certain description of what the system is doing or why.

And without that, the conformance of the concrete entity to any system description cannot be tested.

How to reconcile SST with GST and EA

Management scientists (e.g. Boulding, Ackoff and Beer) have tried to merge SST and GST.

Unfortunately, attempts to merge different approaches can obscure what each has to offer.

Only some parts of SST fit GST, the rest of SST might more accurately be called “Social Entity Thinking”.

SST

Let us ignore natural systems (the solar system, the Krebs cycle) and focus on designed systems.

Much SST is concerned – one way or another - with concepts called purposes, motivations, goals, values and the like.

 

Where do the purposes, motivations, goals, values of a designed system come from?

From stakeholders: primarily from the customers of system outputs or services, and the system owners or sponsors

Stakeholders’ goals and other concerns are essential inputs to designers who apply GST when designing a system.

But they aren't generally part of the designed system itself – they appear instead in test cases.

 

What about the purposes, motivations, goals, values and other concerns of human actors who perform roles in a system?

They are certainly relevant to the success of a designed system

They may or may not match those of system owners and sponsors.

SST ideas (rather than GST ideas) might usefully be applied to the organisation, deployment, motivation and management of human actors.

These matters are usually addressed outside an EA team; sometimes in a parallel business change team.

SST and GST

GST is a cross-science theory of how to describe or model real-world entities as:

·         repeatable behaviors (that are or will be performed by actors/components of some kind)

·         orderly systems in the sense of deterministic (even if they lead to chaos in the long-term)

·         discrete-event driven systems (even if they are continuous in reality).

In recent years, scientists have increasingly discussed systems in terms of information processing.

 

In GST terms:

·         the nations, societies, organisations and businesses of human kind are socio-cultural entities

·         some of those entities are describable as systems, some aren’t (as Ackoff said)

·         all can potentially be described as many different systems (as Ackoff said)

·         one person can play different roles in many different systems.

·         most of a person is way, way outside any system description.

 

The problem with much SST is the presumption that all actors employed by an employer (along with everything they touch and do) necessarily form one "system".

 

However, we can reconcile SST with GST by separating meta system from system.

Actors in a design-time meta system define system aims, variables and rules.

Actors in a run-time system follow rules and change variable values.

Actors in the meta system can describe a new generation or version.

Then switch to playing roles in the run-time system.

 

Actors that both describe and act in a system

Definition of run-time system roles

<define and change>                  <idealise>

Meta system  actors <observe and envisage> Run-time system actors

 

For SST to be compatible with GST, there must be change control.

There must be a formal transition from system version N to version N+1.

As there is in an EA framework like TOGAF.

And there is in some social organization practices discussed elsewhere on this web site,

SST, GST and EA

Applying GST means describing a system abstractly, then planning, realising and governing the reality against the abstract description.

E.g. The US constitution was described abstractly, then realised by successive US governments, which have been tested and held to account against the constitution.

Thus, GST is applied all over the world every day in the design of government, business, human and computer activity systems.

TOGAF applies GST to Enterprise Architecture (EA).

 

Principles

“The method proposed by systems theory is to model… multiple interacting components by abstracting from certain details of structure and component.” (Laszlo and Krippner)

TOGAF's generalisations are vital to the overall coherence and consistency of its content framework.

It is built around three general principles:

1)      An enterprise is composed of interoperating building blocks (components, functions, organisation units, roles, actors, nodes).

2)      An enterprise architecture is an abstract (conceptual, logical) description of building blocks, their interactions and behaviors.

3)      The generic meta model is: required behaviors <are assigned to> logical structures <are realised> physical structures.

 

Core terms and concepts

This table shows different names are given to the same general concepts, often at different levels of abstraction, formality or granularity.

 

Behavior elements names

Structure element names

External view

Service, Service Contract

Interface, Boundary, Service Portfolio

Internal view

Process, Value Stream, Scenario

Building Block, Component, Function, Organisation Unit, Role, Actor, Node

 

Core terms can be defined in a way that is general to TOGAF and ArchiMate.

Structural elements (persist between behaviors)

·         Interface: a collection of services requestable by a client; one way to specify a building block, component or other structural node.

·         Building block: an active structure, a performer of required activities, which interoperates with other building blocks.

·         Component: a building block defined by the one or more services it offers to clients.

·         Function: a logical component that clusters cohesive behaviors by some cohesion criterion other than sequence; a subdivision an organisation’s capability (cf. a capability).

A node connectivity, communication or value network diagram can relate structure elements of any kind by the exchange of flows or services.

 

Behavioral elements (run from start to end over time)

·         Service: a discretely requestable behavior that encapsulates one or more processes; it is triggered by an event or service request and produces a result of value; and is definable declaratively in a contract.

·         Process: a behavior composed of steps in a sequence; it is triggered by an event or service request and leads to an interim or final result.

A process, activity or sequence diagram can relate process steps to structure elements.

 

The TOGAF meta model can be tabulated thus:

 

 

Required behaviors

are assigned to

Logical structures/building blocks

are realised by

Physical structures/building blocks

Business

Business Services

Functions

Organisation Units

Roles

Actors

Information Systems

IS Services

Logical Application Components

Physical Application Components

Technology

Platform Services

Logical Technology Components

Physical Technology Components

 

Implicit in TOGAF are the equations: function = logical business component, and organisation unit = physical business component.

The abstract/logical building blocks cluster behavior types that concrete building blocks can be nominated to perform.

The concrete/physical building blocks are nominated to realise or perform instances of those behavior types.

 

Read Building Blocks and Services for more detail.

 

Change from baseline to target system

Enterprise Architecture (from Walker and Zachman to TOGAF and ArchiMate) is about designing, planning and governing system changes.

The presumption is that change control is applied to the transformation of a baseline system to a target system

This change control requires there to be an abstract system description that has been agreed by stakeholders.

And it means that TOGAF aligns it more with GST than SST.

 

Method

Ackoff’s attempts to align SST with GST and classify systems are questionable

However, Ackoff’s more practical “socio-systemic view of organizations” can be seen TOGAF’s “Architecture Development Method”.

Ideas that Ackoff and his contemporary Checkland might recognise in TOGAF include:

·         Start with the business mission, drivers, strategy and goals (and map system elements to them).

·         Define the human activity system before the information systems (IS) before the technologies (IT).

·         Define/bound business systems (also IS and IT systems) by defining heir "emergent properties" - the services they provide.

·         Define "viewpoints" and "value propositions" to fit the perspective (Checkland might say Weltanshauung) of each stakeholder.

·         Define the business as a function/capability hierarchy.

·         Define the network in which business functions/capabilities provide services to each other.

·         Define value/streams/processes as sequential paths through function/capabilities.

 

More about documenting business and software systems

This paper has distinguished abstract systems from concrete systems, and structures from behaviors.

The table below may help you recognise how these ideas appear in describing dynamic business systems today.

System element

System concept

Business in BIZBOK®

Business in TOGAF®

Applications in TOGAF®

Software in UML

Abstract structure node

groups required behaviors/actions

Capability

Function, Role

Logical application component

Class

Concrete structure node

is nominated to perform behaviors/actions

Organization unit, Actor

Physical application component

Object

System output

result required from behaviors/actions

Value delivery

Business Service delivery

IS Service delivery

Output parameter delivery

Abstract behavior

sequences required behaviors/actions

Value stream (steps to delivery)

Scenario, Process (steps to delivery)

Use case, PAR diagram (steps to delivery)

Interaction, Operation

Abstract action

is an atomic behavior

(Elementary Process/Function)

 

Action

Abstract system structure

the network in which nodes interact

Capability/Outcome Network:

Flows between Capabilities.

Node Connectivity Diagram:

Flows between Nodes

Application Communication Diagram:

Data flows between Applications (Interface catalog)

Class Diagram:

Relationships between classes

 

Every flow between concrete structure nodes delivers something of value to the receiving node.

The last flow in an "end to end" stream/scenario/process/use case delivers the value wanted by the end customer/client/user node.

Footnotes on philosophy, science and GST

First, to be clear, I don't mean to say anything below about how people idealise, or abstract concepts from, realities.

(Inheritance, learning, induction, deduction, trial and error, logical reasoning or guesswork; it makes no difference.)

I only mean to say that people’s concepts of realities are abstractions of those realities.

 

On the philosophy and science of description and reality

In reality, the sun emits radiation across a wide range of the electro-magnetic spectrum.

Only a small part of that spectrum is visible to us, and the colours we describe in that light are artefacts of our human senses.

Other animals see light differently:

“It was natural for scientists to assume that bird vision is like human vision… after all, birds and humans are both active by day, we use bright colors as cues.”

But… systematic testing of bird vision revealed something unexpected: Many bird species can see UV light.”

http://www.nwf.org/news-and-magazines/national-wildlife/birds/archives/2012/bird-vision.aspx

 

The relationship of description to reality is curious, and has been debated by philosophers for thousands of years.

At least some idealist philosophers believe that reality is out there – we observe it and envisage it – but can never know it directly.

Our minds idealise realities in the form of concepts or mental models.

For most day to day purposes, our concepts must model realities well enough, else we would not be here.

Let me call this “practical idealism”.

 

Practical idealists presume universals (concepts) are abstractions of particulars (things) that help us recognise, predict and deal with future things.

Similarly, scientists’ theories abstract from realities.

(I don't mean to say scientists arrive at their theories by a process of abstraction from realities, or say anything about that process at all.)

To test an abstract theory, a scientist envisages how a future reality will match the theory, and then conduct a test.

In so far as reality matches prediction, they consider their theory adequate – for now.

 

On mental models

Practical idealism is a philosophy that not only fits how science works, but also suggests how biological evolution led to intelligence.

Evolutionary biologists presume animals form mental models to help them deal with realities.

In response to events, and in accord with their mental models, animals act to achieve desired effects.

To act effectively, animals’ mental models must describe their environment accurately enough.

 

Nobody knows how a brain works, but that does not matter here.

What matters is only that the presence of mental models is empirically demonstrable.

The mark of an intelligent animal is its ability to abstract types from things, to help it recognise, predict and deal with future things.

For example, you see a thing approaching, you recognise it as an instance of a train type, you predict it will run you over, you step off the track.

This demonstrates you have a mental model of a train’s behavior on a track that describes reality well enough.

More generally, if animals’ mental models didn't conform well enough to reality, they would be unable to find food and avoid danger.

Thus, the ability of animals to form mental models is an outcome of biological evolution that enhances survival prospects.

 

Sharing of mental models through communication

Further, evolution has favoured organisms able to communicate mental models of their environment to their relatives.

Honey bees share experiences through communication of their mental models.

One bee tells other honey bees where it found the pollen - and those other bees fly off to share that experience.

Clearly, sharing mental models of experiences and visions gives honey bees an evolutionary advantage.

 

Naturally, members of a species tend to conceptualise realities in similar ways.

We share inheritance of common bio-chemistry; we learn the same thing from similar experiences (e.g. grasping nettles).

We further align our models by intra-species communication; and by accepting social pressures to conform to the norm.

 

Humans have special advantages when it comes to communication of mental models.

Eons ago, cave men were able to translate mental models into and out of sophisticated speech – a big step forward in communication.

Modern humans have the huge additional advantage of using written words and mathematical symbols.

We translate mental models into documented models for posterity, for agreement and for testing.

 

Realising abstract descriptions as concrete systems

As practical idealists presume universals (concepts) are abstractions of particulars (things) that help us recognise, predict and deal with future things.

So scientists’ theories are abstractions of realities that help them predict and deal with future realities.

And system architects system descriptions are abstractions of envisioned concrete systems that help us to build them.

An entity is a system whenever and wherever it matches an abstract system description.

 

In the special case of a software system, the run-time system is the concrete system, and the software is the abstract system description.

Perhaps the pinnacle of our descriptive ability is the ability to write a description so precise (in software) that a computer can realise it in an operational system.

When GST ideas were aired by von Bertalanffy, Boulding and Ashby in the 1940s and 50s, computers were not in the picture.

The subsequent birth of computer science can be seen as a vindication of the notion that there is a cross-science general system theory.

And now, artificial intelligence software is marked by its ability to abstract types from things to help it recognise, predict and deal with future things.

 

Software systems can be seen as a special application of GST.

However, they don’t exhibit some features von Bertalanffy’s speculated might be “general” to all systems.

That is why some of von Bertalanffy’s notions don’t appear in this update of GST.

And why homeostasis, a focus of early system theorists, is not presented here as a general system property.

 

Activity systems are temporal

An entity is a system whenever and wherever it matches an abstract system description.

In the special case of an activity system, the system description defines behaviors.

When an activity system stops exhibiting behaviors, the system no longer exists.

When a living tiger’s organs stop working, the tiger dies.

When the planets orbiting our sun fall out of orbit, there will be no solar system.

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

 

What remains when an activity system stops running?

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

But the question here is rather: 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.

An entity is a system whenever and wherever it matches an abstract system description.

 

 

All free-to-read materials at http://avancier.website are paid for out of income from Avancier’s training courses and methods licences.

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