Modelling a continuously varying system – using system
dynamics
This page is published under the terms of the licence
summarized in the footnote.
All
free-to-read materials on http://avancier.website
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.
This is the second of three papers on discrete event-driven dynamics,
continuous-variable dynamics, and how they are related.
Contents
Running a model and proving it
System dynamics modelling – summary
process
System dynamics modelling – detailed
process
Commentary
on system dynamics modelling
Conclusions,
remarks and links
Activity systems feature regular, or determinate, or reproducible behaviors.
They are dynamic, meaning the state of the system changes over time in response to events or forces.
Forrester (1971)
promoted System Dynamics as tool for system observers to describe system behaviors in terms of stocks and flows.
A stock is a dynamic set of things – it has a number of members - a quantity - a stock level.
A flow between two stocks represents events that change stock levels over time.
Consider this example.
A growth in the stock of |
plants |
will increase the stock of |
oxygen |
A growth in the stock of |
animals |
will deplete the stock of |
oxygen |
And this one.
A growth in the stock of |
sheep |
will increase the stock of |
wolves. |
A growth in the stock of |
wolves |
will deplete the stock of |
sheep |
Note we can model the discrete short-term interactions between two stocks as “deterministic”.
However, the long-term impact of many interactions on their populations can be “chaotic” rather than homeostatic.
For more, read Modelling a continuously varying system using System Dynamics.
A model is an abstraction (or theory) of an
observed or envisaged reality.
A system description is a model of an
operational system.
An operational system is a realisation of a
system description.
How to prove a system description models an
operational system?
You must test how well the operational
system matches its description.
The match must be near enough to satisfy you, the tester.
In System Dynamics, there are three systems:
1. The real-world operational system that is modelled
2. A static system description (design time model)
3. A dynamic system description (run time model).
Drawing the description and running it can be seductive; it does not prove that the description models the reality
Until tested, the description remains a theory; and when tested, the mismatch with reality may be dramatic.
So yes, a continuously varying system can be modelled as a closed system of stock levels and
inter-stock flow rates.
The stock-flow models can be seen as abstractions from entity-event models made of deterministic discrete event-driven systems.
However, systems thinkers use the tools to model real-world behaviors where the rules are unclear, perhaps unknowable.
So beware that the model is often a declaration of a theory, rather than a proof.
While the event-driven behaviour of individual
actors may be deterministic, the behaviour of a whole population of actors may
appear not to be.
Multiple simultaneous actions and interactions
between actors may lead to unpredictable or chaotic outcomes in the long run.
Agent-based
modeling or system
dynamics can be used to model such a system.
The purpose of system dynamics is not to draw
diagrams directing designers how to build a system.
It is to mimic or predict the outcomes of the
built system - by running the system dynamics model as a simulation.
System dynamics is a system simulation method grounded in general system theory.
The systems of interest are ones that can be represented as stocks related in causal loops by flows.
The stocks and
flows are abstractions from the actors/entities and the activities/events of
event-driven system models.
The quantitative attributes
of stocks and flows are abstractions from the qualitative attributes of
event-driven system models.
A system dynamics model is
limited to |
An event-driven system model
can feature |
Quantitative variables - stock levels – are maintained |
Qualitative variables as well as quantitative ones |
Aggregate entities - stocks of items - are modelled |
Individual entities as well as stocks of them |
Events are time units - a flow rate is an aggregate of discrete real-world events. |
Individual events that represent real-world happenings - as well as time-unit events. |
One event at a time |
Parallel events (provided
they affect different parts of the system state) |
Enterprise architects do need the richer semantics of event-driven system models.
An event-driven system model
contains a wider and more varied collection of entity types, attribute types
and event types.
System dynamics models, and their possible relevance to EA, are discussed below.
The ontology of
the approach may be distilled as:
System dynamics |
Models of stocks and flows <create and use> <idealise> Modellers <observe and envisage
> “Causal loops” |
First, you observe or envisage a system – be it real or imagined – be it mechanical, biological, sociological, economic or political.
Then build a descriptive model of it, and set that model running as a software system.
For example:
1) Observe or envisage a dynamic real world system (e.g. a causal loop in which wolves eating sheep reduces the number of edible sheep)
2) Build a static system description of stocks (wolves and sheep) and flows (e.g. birth, death and predation rates) in a mathematical system dynamics model
3) Run a dynamic software system to simulate what would happen in real world if it follows rules of the system dynamics model (e.g. will the sheep population crash to zero?)
Fans of
agent-based and system dynamics models are interested in the idea that
complexity “emerges” at the macro level from simplicity at the micro level.
Individual
actors, following simple behavioral rules at a micro level, can generate
“complex” or “chaotic” behavior at a macro level.
The words
“emergent”, “complex” and “chaotic” may be interpreted in various ways (as
discussed in other papers).
In this context,
they usually mean that macro level outcomes are unpredictable and unexpected by
observers of the system.
All operational systems are transient islands of rule-following entities in the continuously unfolding process that is the universe.
System descriptions are abstract or theoretical descriptions of those operational systems.
“All systems, everywhere, consist of these
two kinds of concepts --levels and rates--and none other.
Such a statement is powerful in simplifying our view of the world.
A financial report is presented on two different pages—the balance sheet and the profit and loss statement.
All numbers on the balance sheet are levels representing accumulations that have evolved over time.
The profit and loss statement represents the flows that cause the levels to change.” Forrester 1996.
Forrester’s opening statement is questionable – a position statement - a thesis about the nature of systems.
He deliberately simplified our view of systems by abstracting quantities/numbers from qualities/types.
He reduced all systems to stocks and flows described in mathematical expressions.
A stock is a
level – a quantity - abstracted from a set of individual actors or entities
(e.g. quantity of wolves or sheep).
A flow is a rate
– a quantity per time unit - abstracted from a set of individual activities or
events (e.g. quantity of sheep births or deaths per week).
Forrester limits his system theory by asserting that all systems consist of nothing but levels and rates expressed as numbers or mathematical expressions.
This kind of abstraction enables us to build a software system to simulate what some call the “real machine”.
The software system moves forward in time-unit steps, and reports its state after each step to an observer.
Inputs |
Processes |
Output |
Time units |
Flow rates change stock levels according to rules that depend on current stock levels |
Report of system state changes over time |
Forrester surely recognised that a real-world system contains entities with qualitative attributes.
But he ignored these qualities, since his system descriptions are models that contain only these two abstract quantitative concepts.
· A level is the amount of a stock – expressed as a numeric variable value.
· A rate is a flow by which a stock level changes – expressed as a volume (number or formula) per discrete time unit event.
Q: Can variables in system dynamics can be qualitative, e.g. Average Motivation in the Organization?
A: No. Your example is still a quantitative variable.
System dynamics models do not represent qualitative variables such as names and addresses.
Q: Is a system dynamics model a continuous one?
A: Yes and no. The observed or envisaged behaviour may be continuous.
But a system dynamics model - executed in software – proceeds in discrete time steps – and is by definition a discrete event-driven system.
Q: Can a system
dynamics model be used to predict reality?
Perhaps. Running
the model shows what happens to stock levels over time in the model.
That might be useful to predict long-term
outcomes of long-running processes in a corresponding reality.
A system dynamics model might prove useful in predicting where repeated deterministic behaviour will result in surprisingly chaotic outcomes.
But only if the model is an excellent representation of the reality; which
begs the question of how you test that.
Q: Can a system dynamics model be tested?
A: Yes, provided you can compare what the model predicts with real world behaviour.
Some system dynamics models are fanciful (of an imagined reality) but others describe and help us understand a reality.
Seeing where the reality deviates from the model may help you recognise where the model is flawed or insufficient.
There will always be something in the real world that is not in your model, and things change.
So the further you run the model into the future, the more likely it is to depart from reality.
The essential
steps are outlined below.
“Probably
as good [a summary] as it gets at this level of abstraction... It took me half
a dozen videos.” (Gene Bellinger, see references
below)
·
Scope the
system in terms of stocks
o Define the state of your system as a collection of quantitative variables.
o Consider each variable as representing the level of a stock (in effect, the state of a narrower subsystem).
·
Draw a
causal loop diagram
o Draw a diagram that shows every relationship between two stocks (or the same stock) as a link arrow.
o
Mark
a link positive if the two
stocks interact by changing in the same direction (both up or both down).
o Mark a link negative if the two stocks interact by changing in opposite directions (one up, one down).
·
Define
the time steps
o Define how long each time step will be in the context of entity and model life times.
·
Define
the flow rates
o Define the effect of one stock on another (or the same stock) as a flow rate that increases or decreases the stock in a given unit of time.
o Define any flow rates that will be defined when initialising the model.
·
Initialise
the model
o Set the initial stock levels to whatever variable values you choose.
o Set any still-to-be-defined flow rates to a fixed value or the result of a formula
·
Run the
model
o Animate the system behaviour by running the model forward one time-unit step at a time.
The table below
draws an analogy between the design, building and running of software systems
and system dynamics modelling.
Software system development |
System dynamics modelling |
Requirements |
Scope the system in terms of stocks |
Architectural
design |
Draw a causal loop diagram |
Detailed
design |
Define the flow rates |
Code
and deploy |
Initialise the model |
Run
the system |
Run the model |
A system dynamics
Model describes the world in terms of four abstract concepts:
· A Stock is an aggregate’s level or amount: e.g. a stock level, a water volume (beware these are variables in general system theory).
· A Flow adds to a stock or subtracts from it.
· A Variable is a value used to calculate a stock level or flow rate; it can be an equation that depends on other variables, or a constant.
· A Link makes a value from one stock or flow available to another stock or flow.
The steps are elaborated below.
System dynamics can be applied to any situation that is describable as variable stocks connected in feedback loops.
The process must start by identifying the entities/stocks whose level you care about.
Later, the system boundary may expand as additional inter-stock dependencies are recognised.
You have to
consider whatever you have in mind (a business, a society) in terms of
variables that can each move upwards or downwards.
A stock level is an abstraction from a set of discrete individuals.
The individuals can be large or small, teams or people,
pounds or pennies, bodies or cells, countries or villages.
The stock level
could be pennies in a bank balance, human population, or the sum total of human
happiness.
You define the state of your system as a collection of such quantitative variables.
And consider each variable as representing the level of a stock (in effect, the state of a narrower subsystem).
A predator-prey system is often used to illustrate the idea.
The wolves-sheep illustration below comes from http://ccl.northwestern.edu/netlogo/docs/systemdynamics.html.
We name the stocks.
· sheep
· wolves
Both stocks will be increased and decreased by birth and death events. The wolves will deplete the stock of sheep by killing and eating them.
Consider each variable to be the stock of a subsystem that is increased and decreased by events.
Draw a diagram that shows every relationship between two stocks (or a stock and itself in the case of self-reproducing entities).
Mark a link positive if the two stocks interact by changing in the same direction (both up or both down), e.g. sheep population up, wolf population up.
Mark a link negative if the two stocks interact by changing in opposite directions (one up, one down), e.g. wolf population up, sheep population down.
Now you have causal loop diagram.
A feedback loop can be indirect. You might represent human happiness as a variable stock level.
· Happiness is increased by consumption of items in a food stock.
· The food stock is replenished by food item purchases.
· The food item purchases deplete a bank account.
· The bank account is replenished by payment per work hour.
· Work hours decrease happiness (a silly example, but silly and profound models are equally buildable and runnable).
The model will advance in time steps. How long will each step take? One second? One hour? One year?
Define this in the context of the natural life time of individual items in a stock (say 2 years).
And the expected life time of a simulation (say 50 years).
Define the effect of one stock on another (or the same stock) as a flow rate that increases or decreases the stock in the given unit of time.
· sheep-births = sheep-birth-rate * sheep
· sheep-deaths = sheep * predation-rate * wolves
· wolf-births = wolves * predator-efficiency * predation-rate * sheep
· wolf-deaths = wolves * wolf-death-rate.
Define any flow rates that may be set or changed when initiating the model.
· sheep-birth-rate = a fixed value, a fraction of the population per year
· wolf-death-rate = a fixed value, a fraction of the population per year
· predator-efficiency = a fixed value
· predation-rate = the result of a formula.
Now you have a system dynamics model.
Note that in this wolves-sheep system, all sheep die by being eaten, and wolf births depend on eating sheep.
Before you can run the model, you have to initialise it.
Set the initial stock levels to whatever variable values you choose.
· sheep = 100
· wolves = 30
Set any still-to-be-defined flow rates to a fixed value or the result of a formula.
Set the natural birth and death rates to a fraction of the population per year.
· sheep-birth-rate = 0.4
· wolf-death-rate = 0.15
Define the predation rate and efficiency.
· predator-efficiency = 0.8
· predation-rate = 3.0E-4
Now you can animate the system behaviour by running the model forward one step at a time.
The values of the system's variables change deterministically, predictably - with each time unit event - exactly as your model defines
Yet the long-term
outcomes of long-running orderly processes can be surprising. (See http://ccl.northwestern.edu/netlogo/docs/systemdynamics.html.)
“System dynamics is an approach to understanding the behaviour of complex systems over time.
It deals with internal feedback loops and time delays that affect the behaviour of the entire system.
What makes it different from other approaches is the use of feedback loops, stocks and flows.
These elements help describe how even seemingly simple systems display baffling nonlinearity.” Wikipedia
The word “complex” in the first sentence is redundant, and perhaps misleading. System dynamics can be used to model
· a simple or complex system (all introductory examples are simple)
· a linear or chaotic system (regardless of whether the system is simple or complex)
· an orderly or random system (regardless of whether the system is simple or complex, linear or chaotic).
If need be, you could model a random system, which responds to events in unpredictable ways, by introducing random numbers into the mathematical expressions.
But all the examples I have seen are orderly systems, meaning the values of the system's variables change deterministically with each time unit.
Still, over time, the system stocks may grow dramatically, or be exhausted so that the system grinds to a halt. Or both! (See references)
Every model you build of an operational system is an abstraction.
You select the entities (or stocks) and events (or flows) most directly relevant to what you seek to understand or influence.
Since your model is an abstraction, it may omit entities or events that turn out to be important to your interest in the real world.
If the model’s behaviour does not resemble your experience of a corresponding real-world operational system, then you can try to modify the model until it does.
A closed model of an
open world
A system dynamics model is closed, but the real-world operational system that it models is open.
The ultimate test of a system dynamics model is that, when run, it mimics past and/or predicts future real-world behaviour.
If it fails that test, you can incrementally widen the model to capture more influences, but you can never reach the edge of the real word.
For natural, social, and business systems, the model will never be perfect.
Size and complexity
A system dynamics model can grow to be large; Gene Bellinger tells me one has 100,000 mathematical expressions.
That sounds a lot but enterprise architecture is about incredibly large and complex systems of systems.
An enterprise’s software systems may have millions or billions of executable instructions.
And what the programmer writes as one executable instruction may delegate work to many thousands of machine-level instructions.
How verify a system
dynamics model?
System dynamics is seductively interesting.
My slide show introduces system dynamics using the model of wolves predating sheep outlined above.
It starts with a static discrete event-driven system, then gradually abstracts from that a runnable system dynamics model.
It shows slides of long-term outcomes from running the model.
It all looks plausible, until I ask if anybody has noticed a flaw.
The wolves survive by eating sheep; but the sheep live on thin air!
There is no stock of grass, no stock of sunlight, no stock of rain, and how to represent temperature?
The more complex you make the model, in an attempt to reflect the complexity of reality, the harder it is to understand the model.
No matter how far you extend the model, it remains a closed model.
You don't know if you have left out something significant in the real world.
You don’t know if the rules of real world behaviour will change as time passes, or events happen.
How to verify the system dynamics model?
You can run it in parallel with the world, continually validating the former against the latter.
You’ll surely expect the model to fail now and then?
System dynamics v
discrete event-driven systems
Remember: the stocks and flows are abstractions from the actors/entities and activities/events of event-driven system models.
The quantitative
attributes of stocks and flows are abstractions from the qualitative attributes
of event-driven system models.
Enterprise architects do need the richer semantics of event-driven system models.
An event-driven system model
contains a wider and more varied collection of entity types, attribute types
and event types.
However, a system dynamics model does hold some information not in an event-driven system model; it holds the mathematics of flow rates.
IF your system dynamics model is accurate, then it MIGHT be useful as a predictor of long-term real-world outcomes.
Business information system models open systems that monitor and direct individual entities and events in the wider world.
System dynamics models closed systems of cyclical behaviours that increase or decrease entity populations.
The population can be of anything – be it natural, biological, social, financial or physical.
At a
cosmetic level, data flow diagrams used in EA and causal loop diagrams used in
System Dynamics look similar.
On
deeper analysis, there are important differences and they are drawn for
different reasons.
Consider
a DFD that shows
·
gas
meters that send meter readings to
·
a
billing system that sends invoices to
·
customers who send payments to the billing system, which maintains
customer account records.
All
three data flows contain qualitative attributes (identifiers, names, addresses
etc.)
In converting
the data flow diagram into a causal loop diagram those qualitative attributes
are lost, and some quantitative rules must be added.
And
why would you want to do it?
The reason would be to mimic past or predict future changes in the volumes of stocks/populations (gas stocks, customer accounts) over the long term.
“System dynamics uses computer simulation models to reveal how known structures and policies often produce unexpected and troublesome behavior.
The computer models are constructed from descriptive information that usually is already known.
Such information relates to who is striving to do what, the information that each person has available, time delays in taking action, and what individuals will do under a variety of pressures.
The same approach carries over to non-human systems in nature and physical change.” Forrester 1996
You might build a model that incorporates the average delays between orders, deliveries and payments
And discover that at run-time there is a cash flow problem, a result of how money flows between your account and other accounts in the wider system.
Predicting chaotic behaviour is useful if we want to limit it, and/or optimise resource usage.
Stocks and flows (queues, bottlenecks, hospital beds and nurses) are clearly a concern in business ystems.
Architects might want to simulate the behaviour of the system over time, looking for chaotic behaviour, looking to optimise the flow rates and use of resources.
But I haven’t actually met an architect who was asked to do that.
A system dynamics model (be it in a spread sheet or a
software tool like Insight Maker) could help us simulate behaviour over time.
The trouble is that the real business will always be affected by events outside the model.
(Changing customer tastes, competitors' advertising, inflation, wages, share prices, exchange rates, government policy, Donald Trump's poll rating, and so on ad infinitum).
There will always be something in the real world that is not in your model, and things change.
So the further you run the model into the future, the more likely it is to depart from reality.
You might in
theory be able to predict the long-term outcome of a discrete event-driven
system by system testing.
But that would require
a degree of testing that is way beyond what can usually be achieved in
practice.
While the
event-driven behaviour of individual actors may be deterministic, the behaviour
of a whole population of actors may appear not to be.
Multiple
simultaneous actions and interactions between actors may lead to unpredictable
outcomes.
Agent-based modeling or system
dynamics might be used to model such a system.
This paper discusses Forrester’s system dynamics models of continuously varying systems.
System dynamics is used to model analogue or continuously varying systems and unpredictably chaotic systems.
(Though when run to simulate reality, the model actually runs as a discrete time event-driven system.)
The next paper describes converting a model of event-driven dynamics to a model of
continuous-variable dynamics.
But remember, enterprise architecture will always depend on the richer semantics of event-driven system models.
For
more on System Dynamics, here are links to some of Gene Bellinger’s
videos
Gene posted a summary here http://www.youtube.com/watch?v=wiYLx5a1VBk.
For illustrations, see Gene’s video made using Insight Maker http://www.youtube.com/watch?v=wiYLx5a1VBk.
Gene
says this
might be a better reference than the one to BCtD... https://www.youtube.com/watch?v=uH5zM7J-eHU
Footnote: Creative Commons Attribution-No Derivative Works Licence
2.0 28/07/2017 17:15
Attribution: You may copy, distribute and display this copyrighted work
only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and
include this footnote at the end.
No Derivative Works: You may copy, distribute, display only complete and verbatim
copies of this page, not derivative works based upon it.
For more information about the
licence, see http://creativecommons.org