System
coupling patterns (archetypes)
Copyright 2019 Graham Berrisford. One of about
300 papers at http://avancier.website. Last updated 31/05/2019 18:30
The term “complex system” has been used widely
and with various meanings discussed in Complexity explained and related papers.
One kind of
complexity can be found in the way systems or subsystems are coupled to each
other.
Coupling is the relating of systems, as subsystems, in a wider system.
This paper discusses several ways that systems may be coupled, classified as in the structure below.
Contents
Abstracting dynamic systems from passive structures
Hierarchy: Client-server
layering
A design pattern is
a shape or structure of elements that commonly appears in system design.
It is a tried and
tested way to design a system to address particular problems or meet particular
requirements.
The patterns in this paper are relevant to both formal software systems and fuzzy social systems
“If
you think you have a pattern, you must be able to draw a diagram of it.
This is a crude, but vital rule. If you can't draw it, it isn't a pattern.”
“A pattern defines a field of spatial relations, and it must always be possible to draw a diagram for every pattern.”
Christopher Alexander (1979) in The Timeless Way of Building
OK, but his paper
describes patterns in text; leaving the diagrams to companion slide shows.
Design pattern pairs
A design pattern
pair is a pair of contrasting patterns that suit different situations.
Architects choose
between alternative patterns by trading off their pros and cons.
This paper discusses several ways that subsystems may be coupled, loosely classified and paired as shown in this table.
Anarchy |
Hierarchy |
distributes |
centralises |
Network |
Hierarchy |
Point-to-Point or Mesh |
Hub and Spoke |
Peer-to-Peer |
Client-Server |
Chain or Choreography |
Fork or Orchestration |
Every structure or system designer has to strike a good-for-the-context balance between hierarchical and anarchical patterns.
Different patterns may be mixed in one design, and used at different levels of system design.
A system may interact with one, a few or many other systems.
Wherever two systems or subsystems interact, a structural relationship may be drawn between them.
Connecting all the subsystems by these relationships reveals a communication structure, a network or a hiearchy.
This first pair of
patterns is highly generic.
It reappears in
different guises in the other patterns discussed below.
This is a design
pattern in which a node can be connected to any other node.
It is anarchic in
the purest sense of the term, meaning there is no hierarchy.
Real world networks have been studied extensively.
E.g. the world-wide-web, the internet, energy landscapes, biological (cell-to-cell and protein-to-protein) networks and social networks.
Some have proposed such diverse networks can “self-organize” themselves.
Small world network
One
idea is that as a network grows, it tends to minimises the number of steps from
one node to another.
Mathematically speaking, in such a “small-world'' network, the number of steps grows in proportion to the logarithm of the number of nodes.
Scale-free network
Another idea is that as a network grows, the number of major “hubs” with many connections increases, along with minor hubs between the major hubs.
The complexity of a scale-free network lies in the orderly patterns it imposes on the chaos of a random network with the same number of nodes.
These ideas may be useful to designers of large systems in which actors or subsystems must communicate.
However, it turns out that scale-free networks are rare in nature and society.
“The universality of scale-free networks remains controversial.
Across [nearly 1,000] networks, we find robust evidence that strongly scale-free structure is empirically rare.
Furthermore, social networks are at best weakly scale free, while a handful of technological and biological networks appear strongly scale free.” Scale-free networks are rare Nature, 2019
This is a design
pattern that divides a node into subordinate nodes.
The nodes or
subsystems are related as “higher” to “lower” in what people often call a tree
structure.
A rule of thumb for
division: divide one into about seven (the Miller number, as many things as
people can hold in their heads at once).
A rule of thumb for
decomposition: stop at three or four levels (as many bottom level things as a
person or team can manage over time).
Federation and
subsidiarity (levels of control)
Federation means coupling several distributed subsystems, states or organizations under one central authority.
The
central authority is usually seen “higher” than the local, but almost always delegates
some authority downwards.
“Subsidiarity”
is widely promoted as organizing principle
for a federation (like the US or the EU).
The idea is that matters ought to be
handled by the lowest level authority with the required competence.
Decisions should be taken at a local
level if possible, rather than by a central authority.
In
classical cybernetics, this pattern is a technique for organizing a large
and/or distributed system.
The
idea is to organise the management of an organization as a hierarchy of
control-target systems.
When
a lower level system detects a state variable has moved out of range (an
exception), it passes control to a higher-level control system.
The
higher level system returns with a direction to the lower-level system.
See Beer’s ideas for discussion of this idea.
The
principle of subsidiarity may help us understand how biological and social
entities work best.
It
is about how to regulate behaviour efficiently and effectively, but it is not
“self-organising” in the sense below.
Balancing the
patterns
In practice, the optimal structure may employ both ideas.
There may be a network structure with each node in a hierarchy.
The systems of interest here are not passive structures, they are activity systems.
They contain subsystems that interact with each other and/or with entities in their environment.
In accord with the “primacy of behavior” principle, they are defined by their behaviors or dynamics.
The system is composed of interactions between its constituent subsystems.
Abstracting system
interactions from network relationships
Any two subsystems, connected by a relationship in network structure, may interact in several different processes.
So, the complexity of a system in which subsystems interact is a different from the complexity of the network structure that connects them.
A complex network of connections (or acquaintances)
may be used for simple interactions.
Conversely, a simple network of connections may be
used for complex interactions.
Note,
moreover, that actors in one communications network may interact in several different
(complementary, cooperating, competing or contrary) systems.
E.g. the
people in one city may vote in both local and national government elections -
and vote for different parties in each.
Abstracting system
interactions from the communication stack
Every
communication act between human or computer actors depends on the use of
communication stack between them.
When
co-located humans converse, they use neurons > vocal chords > sound waves
> ear drums > neurons.
When remotely
distributed humans communicate via a telecommunications network, the lower
levels of the communication stack are hidden from them.
The depth and
complexity of the telecommunication stack is irrelevant to most systems of
interest that actors cooperate in.
Systems (and actors play roles within them) can interact by forces, energy, matter or information.
The last of those, interaction by communication of information, is the main interest in sociology and software sciences.
Should we allow direct communication between any pair of nodes or
subsystems, or centralise it in one place or subsystem?
This is a design
pattern in which subsystems talk to each other directly.
It can be faster
and simpler where inter-subsystem communication is 1-to-1 and the endpoints are
stable.
But coupling
subsystems to each other can hinder change or agility.
This is a design
pattern in which subsystems communicate via a mediator.
(In the
classification scheme here, the mediator is seen as “higher” than the
subsystems.)
This pattern couples subsystems indirectly
rather than directly.
It can be good
where the endpoints are volatile; but can be more complex and slower.
Consider
this example of organizations involved in emergency response.
https://ec.europa.eu/echo/what/civil-protection/emergency-response-coordination-centre-ercc_en
“The Emergency Response Coordination Centre coordinates the delivery of assistance to disaster stricken countries,
such as relief items, expertise, civil protection teams and specialised equipment.
It acts as a coordination hub between participating states, the affected country, and civil protection and humanitarian experts.”
Each
organization has its own command hierarchy but they are called to act in the
same situation.
The
coordination centre does not command; it doesn’t have authority within any of
the organizations.
It
ensures each organization has information about the state of the situation and
each other organization.
This analogous to event-driven architecture (EDA) in software design.
By using a central publish-subscribe mechanism, EDA completely decouples the senders and receivers of messages
By contrast, in the human example above, you’d expect the human actors in the distributed subsystems to meet and communicate directly at some point.
The
hub centralises communication (rather control) between subsystems.
It
can help to coordinate subsystems efficiently and effectively, but is not
“self-organising” in the sense below.
Balancing the
patterns
In practice, the optimal structure may employ both ideas.
There may be point-to-point communication within subsystems that communicate via a hub.
Any system may delegate work to another system, as a gentleman delegates
polishing shoes to his butler.
The delegation relationship between two systems may be two-way, or
one-way.
Should we treat all subsystems as peers, or arrange them in layers
according to the nature of their responsibilities?
This is a design
pattern in which any subsystem can request work of any other.
A cyclic dependency
between two subsystems is said to create a fragile structure, difficult to
understand and maintain.
But some cyclic
dependencies are inevitable, especially between the largest or most
coarse-grained of subsystems.
Self-regulation (via
causal loops that connect subsystems)
“Ashby
popularised the usage of the term 'cybernetics' to refer to self-regulating
systems” Wikipedia 2017
Here, self-regulation means (as in
homeostasis) constraining the range of a variable’s values, or the population
of a stock, between upper and lower bounds.
The
idea of homeostasis dates back to the 1800s if not before.
It often
appears in sociology and social systems thinking discussion.
In
truth, many societies do not stay in a stable state, their state and their
nature advances continually.
Nevertheless,
homeostasis does have an important place in cybernetics and wider systems
thinking.
Weiner wrote about
the science of control in the animal and the machine.
Self-regulation
can be seen in natural systems – as when predator and prey populations are
balanced by interactions between them.
And
seen in designed systems – as when a thermostat controls the behaviour of a
heater/cooler machine
It may appear that predators and prey are peer-to-peer
subsystems, but thermostat and heater are higher and lower subsystems
However, in both cases, there is wider system
composed of two subsystems connected by a causal loop.
The asymmetry in the second example is as
much in our mind as in reality.
Does the thermostat control the heater? Or
does the heater control the thermostat?
Arguably, the “control” lies more in the use
of the thermostat by some higher level entity – which manipulates the
thermostat’s setting.
Where
one system regulates the state of another, this is not a “self-organising”
system in the sense below.
The
organization of the controlled system is not changed by the regulator.
This is a design
pattern in which higher subsystems in one “layer” delegate work to subsystems
in lower layer.
Given
a system structure with co-dependent subsystems, suppose you restructure it to
eliminate all cyclic dependencies.
The result will be
a hierarchical client-server layered structure (which often resembles what
Barry Boehm called a Mosque Shape).
This pattern is
widely used to make the structure of a complicated system understandable and
manageable.
Client-server computer architecture
· Programming language,
· OS,
· Device drivers and CPU instruction sets,
· Logic gates inside chips
Client-server network architecture
· FTP
· TCP
· IP
· Ethernet
· Cable
Client-server software architecture
·
UI
·
Logic
· Database
Client-server enterprise architecture
·
Business
·
Apps
and
· Technology
Balancing the
patterns
In practice, the optimal structure may employ both ideas.
There may be peer-to-peer communication within each client-server layer.
A design decision that may recurs at different levels of design.
Should we distribute process
control to many places or subsystems, or centralise it in one place or
subsystem?
This is a design
pattern in which subsystems interact directly to complete a process.
It distributes
intelligence about the overall processes
Each subsystem
calls the next subsystem in a peer-to-peer fashion.
This is a design
pattern in which one subsystem schedules other subsystems.
It centralises
intelligence about the overall process or workflow.
Balancing the
patterns
In practice, the
optimal process control may employ both ideas.
The GRASP pattern
can help to find the optimal balance.
This paper has distinguished several ways that subsystems may be coupled.
To assist in presentation and explanation the coupling varieties are classified in a table.
Anarchy |
Hierarchy |
distributes |
centralises |
Network |
Hierarchy |
Point-to-Point or Mesh |
Hub and Spoke |
Peer-to-Peer |
Client-Server |
Chain or Choreography |
Fork or Orchestration |
In human
society, one “organization” or “institution” may involve all these kinds of
coupling.
The aim here is
not to present an exhaustive list of design patterns.
However, one aim is to prepare the ground for discussion of self-organization.
Self-organization
(mutation)
System change may be divided into many different types starting with:
·
state change: changing the values of given state
variables (typically triggered by inputs)
·
behaviour change:
changing the variable types or the rules that update their values.
While
watching some actors playing a game of cards, you might observe both kinds of
change.
· state changing actions: when actors play their roles according to the rules, they win “tricks” that advance the state of the game.
·
game changing
actions: actors stop the
game, agree a change to the rules, then play on; this creative act changes the
game itself.
When
people speak of “self-organization”, they rarely make clear which kind(s) of
change they are thinking of.
Consider a system of predator and prey
populations, which grow and shrink as a result of their interactions
That system is better called self-regulating than self-organizing.
Since the latter implies changing the
populations or how they interact.
It implies adding or removing a population,
or changing the rules by which one population affect another.
Ashby rejected the idea that a system can change itself by self-organization.
“One
of Ashby’s goals was to repudiate that interpretation of self-organization,
commonly held, that a machine or organism can change its own organization.”
Instead
he postulated “A new higher level of the machine was activated to reset the
lower level's internal connections or organization.”
(Goldstein’s
introduction to Ashby’s 1962 treatise on
self-organization.)
Ashby’s higher and
lower level machines can be seen as “coupled” in a wider or aggregate machine.
But the aggregate
machine is only ever partially self organising, since one part of the aggregate
machine always drives the change to the other part.
Read second order cybernetics for a deeper analysis of
self-organisation.
John Flach
tells me, some of these concepts appear in
Handy,
C. (1992). Balancing Corporate Power: A New Federalist Paper. Harvard
Business Review. 70(6), November–December.
Sage,
A.P., & Cuppan, C.D. (2001). On the
systems engineering and management of systems of systems and federations of
systems. In Information knowledge systems management,
2 (pp. 245–325). IOS Press.
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..