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.

 

A continuously varying system can be modelled using “systems dynamics” as a closed system of stock levels and inter-stock flow rates.

System dynamics modelling tools apply general system theory principles.

The stock-flow models can be seen as abstractions from the entity-event models one can make of deterministic discrete event-driven systems.

However, systems thinkers use the tools to model real-world behaviors where the rules are unclear, perhaps unknowable.

Also, the deterministic nature of the system might be questioned, and it is difficult-to-impossible to test the model against reality.

So the model is often a declaration of a theory, rather than a proof.

Contents

Introducing system dynamics. 1

System dynamics modelling – summary process. 4

System dynamics modelling – detailed process. 5

Commentary on system dynamics modelling. 8

System dynamics for EA?. 9

Conclusions, remarks and links. 11

 

Introducing models

A model is an abstraction (or theory) of an observed or envisaged reality.

A model can be mental, documented or physical.

Mental models are the least stable and shareable, but still count below.

 

A system description is a model (or theory) 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,  but may be imperfect.

 

In System Dynamics, there are three systems:

-1- The operational system that is modelled

-2- A static system description (design time model)

-3- A dynamic system description (run time model).

 

Drawing 2 and running 3 can be seductive, does not prove that 2 models 1; 2 remains a theory, and the mismatch with 1 may be dramatic.

Introducing system dynamics

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 models as abstractions from event-driven system models

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 essence of the method

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.

Abstracting quantities from qualities

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.

Reader’s questions

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.

 

System dynamics modelling – summary process

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

System dynamics modelling – detailed process

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.

Scope the system in terms of stocks

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.

Draw a causal loop diagram

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

Define the time steps

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 flow rates

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.

Initialise the model

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

Run the model

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)

Review the results and refine then model

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.

Commentary on system dynamics modelling

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.

 

System dynamics for EA?

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.

Conclusions, remarks and links

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     24/12/2016 21:56

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