More system theory

Including a few principles

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 18/02/2018 20:39

 

Much of the content in this paper has been moved.

You can find that content in earlier papers under the heading of General System Theory on this System Theory page.

This paper contains what is left over.

Contents

On methodology. 1

On system structure. 2

Principle: systems can be composed and decomposed. 2

Principle: control can be centralised or distributed. 2

On system change. 3

Principle: system state change differs from system mutation. 3

Principle: continuous state change can be modelled as discrete event-driven state change  3

On description and reality. 3

Principle: concrete systems realise abstract ones. 3

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

Principle: realisation differs from translation. 5

 

On system design methodology

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

The conventional business system 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.

Principle: systems can be composed and decomposed

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

Systems and processes can be, and are, composed and decomposed during system design.

 

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.

 

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

 

Systems are decomposed to the level describers regard as atomic elements.

Atomic elements are usually individual actors that can be hired or made to perform the required behaviors.

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

Principle: control can be centralised or distributed

There are general archetypes or design patterns in how system elements interact.

This table identities some contrasting design patterns.

 

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 first three are structural patterns, the last is a behavioral pattern.

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

On system change

Principle: system state change differs from system mutation

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

Principle: continuous state change can be modelled as discrete event-driven state change

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.

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.

On description and reality

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

Principle: concrete systems realise abstract ones

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

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

The main concern here is activity systems, in which structural elements interact in orderly behaviors.

 

A concrete activity 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

 

For example:

 

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

 

Is every entity a system?

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

IBM is an ever changing entity in which stuff happens.

If there is no description of the entity as a system, there is no testable system, just stuff happening.

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

There must be a system description (a type or theory) that the entity conforms to – near enough.

 

Viewpoint

Subject

Predicate

Objects

Philosophy

A type

helps people understand and describe

instances

Science

A theory

helps people understand and predict

realities

System theory

An abstract system

helps people understand and make

concrete systems

 

A concrete system is an island of repeatable behaviors carved out of the universe.

It is a set of describable entities that interact in describable behaviors.

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

 

An abstract system describes behaviors.

When an entity 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 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 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.