System Dynamics

Modelling a continuously varying system

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 14/10/2018 20:21

                                                                 

This paper looks at general system theory concepts through the lens of System Dynamics.

It outlines the ideas of two system dynamics gurus.

·         Jay Forrester (1918 to 2016) every system is a set of quantities that are related to each other.

·         Donella H. Meadows (1941 to 2001) resource use, environmental conservation and sustainability.

 

It differentiates system state change from system generation change.

It differentiates complexity in a system from complexity in the trajectory of system change over time.

Contents

Dynamical systems and chaos. 1

Continuous and discrete dynamics. 2

Feedback loops. 3

Forrester: system as interrelated quantities. 4

Meadows: resource conservation. 5

Proving and using a model 7

Animations of agent-based models. 8

Abstractions of quantities from qualities. 8

A system dynamics methodology. 10

Commentary on system dynamics modelling. 15

System dynamics in EA?. 16

Conclusions, remarks and links. 18

 

Dynamical systems and chaos

The state of a system is dynamic - it changes over time.

In mathematics, dynamical systems theory and chaos theory deal with the long-term behavior of systems.

The interest is not to predict the next state of the system in response to a single event.

It is rather to answer long-term questions like:

·         "Will the system settle down to a steady state?

·         “What steady states are possible?"

·         “Will the system crash or halt?

·         "Does the long-term behavior of the system depend on its initial condition?"

 

System dynamics is an approach that reveals the trajectory of quantitative state changes over time.

What makes it different from other approaches is the modelling of feedback loops in flows that increase and decrease the quantities of stocks.

The stocks can be resources of any kind – materials, energy, organisms, happiness, whatever.

System dynamics reveals how feedback loops and time delays affect the stock levels over the long term.

 

System dynamics is a kind of group dynamics that considers interactions between groups (rather than within a group).

Animating the model reveals the trajectory of changes over time to the size of a group, stock, population or resource quantity.

 

System Dynamics

Stock and flow models

<create and use>                 <idealise>

System modellers <observe & envisage>  Interdependent quantities

 

System dynamics may reveal a system behaves in a way that

·         is non-linear - its stocks increase and/or decrease in an irregular or chaotic way.

·         settles in a steady state – its variable value(s) settle on fixed value(s).

·         has periodic points – it states repeat over time.

 

Steady and periodic states may be “attractive” - meaning the system, when in a nearby state, likely moves towards them.

Continuous and discrete dynamics

Analogue signals, such as a clock with revolving hands, vary continuously.

By contrast, digital signals, such as a time displayed as numbers, advance in discrete steps.

 

The state of a system is dynamic - it changes over time.

A system’s state, such as the position of a planet in its orbit, may change continuously.

By contrast, the state of an event-driven system advances incrementally in response to discrete events.

 

As Ashby pointed out, it is possible to model a continuous system as a discrete event-driven system.

“Often a change occurs continuously, that is, by infinitesimal steps, as when the earth moves through space, or a sunbather's skin darkens under exposure.

The consideration of steps that are infinitesimal, however, raises a number of purely mathematical difficulties, so we shall avoid their consideration entirely.

Instead, we shall assume in all cases that the changes occur by finite steps in time and that any difference is also finite.

We shall assume that the change occurs by a measurable jump, as the money in a bank account changes by at least a penny.

consideration of the case in which all differences are finite loses nothing; it gives a clear and simple foundation;

and it can always be converted to the continuous form if that is desired.” Ashby 1956

Feedback loops

 

Balancing (dampening) loops

The state of the world’s ecology may be represented by three variables: the mass of plants, the mass of animals and the mass of oxygen in the atmosphere.

We all depend on the fact that plants and animals balance the stock of oxygen.

System Dynamics helps to explain how these stocks interact so as to reach a balance.

 

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

 

Every model of the world is a selective abstraction, as this one excludes any other producer or consumer of oxygen.

So the real world is likely to behave differently from a model, to some extent.

 

A flock of sheep and a pack of wolves can be represented by two variables: the quantity of sheep and the quantity of wolves.

System Dynamics helps to explain how these stocks interact.

It employs the idea of causal loop between what Marx and Engels might call opposites.

 

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

 

In "Thinking in Systems – A Primer" Donella H. Meadows wrote that a system generally "goes on being itself... even with complete substitutions of its elements."

In our example, this means that individual sheep and wolves come and go.
What remains stable is only the roles that sheep and wolves play in the described system’s behaviors.

 

Of course, a System Dynamics model does not contain any wolves or sheep.

It models stocks of entities (wolf pack, sheep flock).

There are no individual entities (a wolf, a sheep), unless you count each “1” in a stock total as a model.

It models batches of events (number of sheep killed per time unit).

There are no individual events (a single birth or death), unless you count each “1” in a number of events as a model.

 

Real wolves and sheep realises the abstract system only in so far they demonstrably play their roles

Almost everything real sheep and wolves do lies outside the described system.
And they can act contrary to the system (wolves find another flock on which to predate).
Moreover, the same flock of sheep plays unrelated roles in other systems.

The sheep play roles in a natural system (trimming and fertilising grass); and in a designed system (sheep shearing).

 

Reinforcing (amplifying) loops

Some balancing feedback loops act to keep a system stable.

But sometimes the long-term result of such loops can be “chaotic” rather than homeostatic (the sheep or wolf population crashes).

And other loops reinforce each other so as to deplete a stock to zero, or increase a stock continually.

A system may exhaust a resource it needs: E.g. A moon rocket exhausts its fuel in a few minutes.

A quantity can continually expand or grow: E.g. A business increases its revenue every year.

Forrester: system as interrelated quantities

Jay Forrester (1918 to 2016) was a professor at the MIT Sloan School of Management and the founder of system dynamics

Forrester defined a system as a set of stocks or quantities that are related to each other.

Wherever a change to one quantity has an effect on another quantity, he defined the relationship as an inter-stock flow.

·         A stock is a quantity of entities or units – the stock level is the total number of the entities or units at one time.

·         A flow between two stocks typically represents a batch of events that increase or decrease stock levels.

·         A causal loop connects stocks by flows that increase or decrease stock levels.

 

You may model behavior in causal loops that you regard as continuous.

But when executed in software, a system dynamics model proceeds in discrete time unit steps – which is to say it is a discrete event-driven system.

 

In a System Dynamics model:

·         Each stock is incremented and decremented (at discrete time unit intervals) by inter-stock flows.

·         Each flow has a rate, expressed as events-per-time-unit (e.g. total births per time unit).

 

System Dynamics

Model of stocks and flows

<create and run>                   <idealise>

System modellers     <observe and envisage>     Causal loops

 

Why build a System Dynamics model?

Not to model individual entities and events, but to model the trajectories of quantities over time.

The long term effect of events on a system’s stocks or populations is not predictable from knowing the system’s roles and rules.

It is sometimes possible to mimic or predict that effect by simulating the system, by running a model of it.

A software tool can advance a System Dynamics model step by step, where each discrete event is a time unit.

And thereby show what might happen to stocks or populations over long period of time.

 

Running the model does not test the theory against reality, it only animates the model.

To test the model, you must compare the results of running the model with the real world that is modelled.

So, System Dynamics may be used in a hypothesis-test process.

·         Scope: Observe or envisage an entity as a set of stocks related by inter-stock flows.

·         Abstract: Describe/model the effects of the flows (events) on measurable stock (entity) levels.

·         Realise: Set the abstract model in motion, and note the trajectory of stock level changes over time.

·         Test: Check that stock levels in the real world change over time as they do in the model.

 

Observations:

In System Dynamics there can be three systems:

·         A abstract system description: a static system model, expressed in a causal loop diagram.

·         A concrete software system: a dynamic model of stocks and flows, running in a computer.

·         A concrete reality that the model supposedly represents.

 

Some say System Dynamics shows how complex behavior at the macro level emerges from simple behavior at the micro level.

The distinction is not so much between levels as between ways of measuring complexity, since there is:

·         System state complexity - as in Ashby’s measure of “variety”.

·         Behavior complexity - as in Mcabe’s measure of procedural complexity.

·         System state change trajectory complexity – as may be revealed by System Dynamics.

 

Meadows: resource conservation

Donella Meadows (1941 –2001) was an environmental scientist, teacher, and writer.

She was much concerned with resource use, environmental conservation and sustainability

She is best known as lead author of the influential book “Thinking in Systems: a Primer.”

Seven of the eight declarations below are made explicitly in the book, and the fifth is implicit.

 

1.      A system is a set of things interconnected so as to produce a pattern of behavior over time.

2.      The behavior of a system cannot be known just by knowing its elements.

3.      A system isn’t just a set of things - even interconnected things.

4.      A system is an interconnected set of elements that is coherently organized so as to achieve something.

5.      The achievement (result) of a system is what repetition of its behaviors over time results in.

6.      So, the way to deduce the system’s purpose is to watch how the system behaves.

7.      And purposes are deduced from behavior, not from a declaration of goals.

8.      Intervening (to change the roles or rules of how elements interact) is to change the system.

 

Reverse engineering aims from outcomes

What Meadows calls purposes are probably not purposes as you think of them.

They are not the goals of system actors, or ones declared by managers of the system.

She regarded the outcomes of behaviors, repeated over the long term, as their aims.

This is reasonable for a natural system (e.g. the solar system) that evolves without any intent.

But not for a designed system, whose outcomes may diverge from aims it was designed to achieve.

 

The transience of actors

David Seidl (2001) said the question facing a social system theorist is what to treat as the basic elements of a social system.

“The sociological tradition suggests two alternatives: either persons [actors] or actions.”

 

Meadows characterised a system by its activities rather than its actors.

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

 

Meadows said the actors, which perform behaviors, may come and go.

"The elements, the parts of systems we are most likely to notice, are often (not always) least important in defining... the system." Meadows

"A system generally goes on being itself... even with complete substitutions of its elements." Meadows

 

Individual actors do not appear in a System Dynamics model, except as units in a quantity.

 

The persistence of roles and rules

Meadow’s system is defined by the roles actors play and the rules that govern their activities.

"Change the rules from those of football to those of basketball, and you’ve got, as they say, a whole new ball game.” Meadows

The system repeats its regular behaviors, performing the same operations on the same variables.

It does this until it is stopped or crashes, at which point it may be changed by design to a new system.

 

Changing a system to produce the desired results

Suppose you observe or envisage a system that produces unwanted results (say global warming).

You might build a System Dynamics model to show how those results emerge from repeating certain behaviors.

Then, looking to produce the results you would prefer, change role and rules of the system.

You may then go on to simulate different options by designing and running different System Dynamics models.

 

Observations:

Like Russell Ackoff, Meadows started from a place rooted in classical or general system theory.

Also like Ackoff, Meadows slipped almost unnoticed from there into speaking of a human society as a system per se.

And into socio-political discussion, as though whole societies and economies can be modelled in a closed System Dynamics model.

Economists and systems thinkers like to think and talk this way, and it may be helpful on occasion.

But it is to step away from testable science and towards “scientistic” speculation.

Proving and using a model

A model of stocks and flows in the world declares a theory of how the world works; proving the model is a correct is another matter.

Building a model and running it can be seductive, but still does not prove that it is a good model of reality.

Model validation is an important part of modelling the real world.

 

Testing against changes in real world stocks or populations

When System Dynamics is used to model the real world, there are three systems.

 

Dynamic or static

Concrete or abstract

Description or reality

Open or closed

System 1

Dynamic

Concrete

Reality

Open – has inputs and outputs not mentioned in 2

System 2

Static

Abstract

Description – a theory of 1

Closed – in the sense it excludes much in real world

System 3

Dynamic

Concrete

Description – a simulation of 1

Open – transforms parameters into a report of state changes

 

System 1 is either observed, or else designed and deployed.

An observed system runs in reality before it is modeled.

A designed and deployed system runs in reality after it has been modelled.

In both cases, the concrete system runs independently of any abstract system description, and system testing is how we validate the match of one to the other.

 

So, how to prove that 2 models 1? You must test how well 3 matches 1.

You must compare what running the model predicts against historical state changes, or else against predicted future system state changes.

The model should match that historical data and/or predict those future system states.

Or else, studying the differences may help you recognise where the model is flawed or insufficient.

 

Refining the model

You can try to modify the model until it passes the tests.

You may have omitted entities/stocks or events/flows that turn out to be important to your interest.
You can change anything – the stocks, the flows, the initial conditions, the rules

 

Predicting changes in real world stocks or populations

To predict with confidence, you need to validate the model.

There will always be something in the real world that is not in your model

What you might assume is stable may changes (e.g. global warming).

So the further you run the model into the future, the more likely it is to depart from reality.

And if you don’t like the predicted outcome, the cost-benefit case for changing real-world behaviors is another matter again.

Animations of agent-based models

System Dynamics is based on modelling aggregates.

Agent-based modelling tools can represent the existence of individual stock items as icons on a screen.

A predator-prey model: https://cloud.anylogic.com/#/model/a7018576-3735-4700-b963-9d95611730d7;mode=SETTINGS.

A predator prey agent-based model: https://cloud.anylogic.com/#/model/4f5ce51f-3003-46bb-88b1-d52e67f669e4;mode=SETTINGS.

An insight maker page on modelling: https://insightmaker.com/modeling.

 

Do these add to the story of System Dynamics?

A visual animation of the existence of units in a quantity is one thing.

Modelling individual agents in the real world is different; it would imply capturing qualitative characteristics of real-world individuals.

More to be said here...

Abstractions of quantities from qualities

All systems, everywhere, consist of these two kinds of concepts --levels and flows--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.

 

One might say a design-time SD model “models structures”, since a stock level models the total of individuals in a stock.
However, an individual is modelled only as a unit of 1 in a total, which is the most abstract possible model of an individual structure.

One might say a design-time SD model “models behaviors”, since a flow rate models a batch of events or actions that increase or decrease a stock level.
However, a particular action is modelled only as a unit of 1 in growth or shrink rate, which is the most abstract possible model of a particular action.

One might say a run-time SD model “models the behavior of a stock”, since the output is graph showing quantitative state changes over time.
However, the behavior of a stock is a rather curious concept, since it is individuals’ behaviors that actually cause state changes.
The behavior of a stock, a line on a graph, is an abstraction from an abstraction.

 

An SD models hold only abstract quantitative variables, e.g. stock quantities and flow rates.

Information systems hold also qualitative variables, such as your name, address and voting intention.

Using such a model of reality, a political party’s dynamic information system may send you letters encouraging you to vote.

 

So Forrester’s opening statement is questionable – a position statement - a thesis about the nature of systems.

He surely recognised that a real-world system contains individual entities with qualitative attributes.

He deliberately simplified our view of systems by abstracting quantities from qualities.

 

A stock has a levela number of units, the amount of the stock.

This quantity is abstracted from a set of individual actors or entities (e.g. quantity of wolves or sheep).

A flow has a rate – the rate by which a level changes, a volume (number or formula) per discrete time unit event.

This quantity is abstracted from a set of individual activities or events (e.g. quantity of sheep births or deaths per week).

 

This enables us to build a software system to simulate what some call the “real machine”.

The machine moves forward in time-unit steps, and reports its state after each step to an observer.

 

Inputs

Processes

Output

Initial state variable values    

Flows change stock levels

according to rules that depend on current stock levels

Report of system state changes over time

 

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.

The event-driven behavior of individual actors in the system may be deterministic

But the trajectory followed by the total population quantity may be unpredictably non-linear or chaotic.

 

Comparison with DEDS

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.

Forrester’s stocks and flows abstract from individual actors/entities and activities/events.

Their quantitative attributes abstract from the qualitative attributes of an event-driven system model.

 

 

System Dynamics Model

Discrete Event-Driven System (DEDS) Model

State variables

Quantitative

Qualitative as well as quantitative

Entities

Aggregates – stocks of entities

Individual entities as well as aggregates of them

Events

Time units – batches of events

Real-world events as well as time-units

 

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.

 

Q: Can you abstract a System Dynamics model from a Discrete Event-Driven model

Yes (another paper shows how).

But you cannot recover the discrete event-driven model from the System Dynamics model.

Because the process of abstraction erases all qualitative attributes (names, addresses, descriptions, dates).

It also erases all instance-level entities, leaving only the quantitative volumes of entity types.

 

Q: Can a system dynamics model include qualitative variables, e.g. average motivation in the organization?

Your example is still a quantitative variable (the organizations’s stock of motivation divided by the stock of employees).

However, if an agent-based model represents the existence of individual stock items as icons on a screen.

Then you might then track some variables of those animated items, like their life time, and position on the screen.

More to be said...

A system dynamics methodology

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 six step process - outline

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)

 

1.      Scope the system in terms of quantities you care about

·         Define the state of your system as a collection of quantitative variables.

·         You might think of each variable as the state of a narrow subsystem.

2.      Draw a causal loop diagram

·         Draw a diagram that shows every relationship between two quantities (or the same quantity) as a link arrow.

·         Mark a link positive if the two quantities interact by changing in the same direction (both up or both down).

·         Mark a link negative if the two quantities interact by changing in opposite directions (one up, one down).

3.      Transform the causal loop diagram into a stock and flow model

·         Draw a stock and flow diagram

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

·         Define all variables to be initialised before running the model.

·         Review the structure and logic of the stock and flow model

4.      Initialise the model

·         Define how long each time step will be in the context of entity and model life times.

·         Set the initial stock levels to whatever variable values you choose.

·         Set any still-to-be-defined flow rates to a fixed value or the result of a formula

5.      Run the model

·         Animate the system behavior by running the model forward one time-unit step at a time.

6.      Review the results and refine the model

 

The six step process in more detail

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 (aka system state variables).

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

 

1 Scope the system in terms of quantities you care about

System dynamics can be applied to any situation describable as quantities that can increase or decrease

First, you identify something you care about, and can quantify.

It could be pennies in a bank balance, human population, or the sum total of human happiness.

Later, you can expand the system boundary to include whatever related quantities you recognise.

 

In effect, you define the state of your system as a collection of quantitative variables.

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.

The variables we care about are.

·         Total sheep in a flock

·         Total wolves in a pack

 

Both quantities will be increased and decreased by birth and death events.

The wolves will deplete the flock of sheep by killing and eating them.

 

2 Draw a causal loop diagram

This is not a tutorial on drawing causal loop diagrams, only an outline.

 

Consider each variable to be a quantity that is increased and decreased by events.

Draw a diagram that shows every relationship between two quantities (or recursively in the case of self-reproducing entities).

Mark a link positive if the two quantities 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 quantities 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 quantity.

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

 

This is silly example, but silly and profound models are equally buildable and runnable.

 

3 Transform the causal loop diagram into a stock and flow model

This is not a tutorial on stock and flow modelling, only an outline.

 

Draw a stock and flow diagram.

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 all variables to be initialised before running 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.

 

Review the structure and logic of the stock and flow model.

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.

 

4 Initialise the model

Define how long each time step will be in the context of entity and model life times.

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 quantity (say 2 years).

And the expected life time of a simulation (say 50 years).

 

(Will Harwood tells me there can be delays between the internal steps in the model.

E.g. the time between a stock input and the stock update.

Such delays create can have a major impact upon the effects of feedback in the model.

E.g. oscillations may move in or out of phase with one another causing amplification (in phase) or cancellation (out of phase) as the model evolves.)

 

Before you can run the model, you have to initialise it.

Set the initial stock levels to whatever variable values you choose.

·         Sheep flock = 100

·         Wolf pack = 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

 

5 Run the model

Now you can animate the system behavior 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 behavior of complex systems over time.

It deals with internal feedback loops and time delays that affect the behavior 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)

 

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)

 

6 Review the results and refine the model (repeat)

This section is copied from “Proving and using the model” above.

 

Testing against changes in real world stocks or populations

When System Dynamics is used to model the real world, there are three systems.

 

Dynamic or static

Concrete or abstract

Description or reality

Open or closed

System 1

Dynamic

Concrete

Reality

Open – has inputs and outputs not mentioned in 2

System 2

Static

Abstract

Description – a theory of 1

Closed

System 3

Dynamic

Concrete

Description – a simulation of 1

Open – transforms parameters into a report of state changes

 

How to prove that 2 models 1? You must test how well 3 matches 1.

You must compare what running the model predicts against historical state changes, or else against predicted future system state changes.

The model should match that historical data and/or predict those future system states.

Or else, studying the differences may help you recognise where the model is flawed or insufficient.

 

Refining the model

You can try to modify the model until it passes the tests.

You may have omitted entities/stocks or events/flows that turn out to be important to your interest.
You can change anything – the stocks, the flows, the initial conditions, the rules

 

Predicting changes in real world stocks or populations

To predict with confidence, you need to validate the model.

There will always be something in the real world that is not in your model

What you might assume is stable may changes (e.g. global warming).

So the further you run the model into the future, the more likely it is to depart from reality.

And if you don’t like the predicted outcome, the cost-benefit case for changing real-world behaviors is another matter again.

 

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

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.

 

Complexity and size

Some say complexity “emerges” at the macro level from simplicity at the micro level.

Individual actors, following simple behavioral rules, can generate “complex behavior” at a macro level.

However, if there is complexity, it is not in the behavior, it is the trajectory followed by quantities over time.

 

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 behavior 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 in EA?

EA is based on discrete event-driven system modelling, rather than agent-based modelling.

A business information system models an open system that monitors and directs individual entities and events in the wider world.

A system dynamics model models a closed system of cyclical behaviors that increase or decrease a quantity or entity populations.

 

Emergent properties?

EA is about designed system integration, rather than the accidental or unforeseen side effects of interacting agents.

The primary emergent properties of designed systems or system change are design objectives from the start.

E.g. the emergent properties of stability and motion in the interaction between a bicycle and its rider.

E.g. the desired emergent properties of integrating sales, billing and customer service systems.

 

In biological evolution, civil engineering and EA, other emergent properties are more likely undesirable than desirable.

E.g. the emergent property of the wind interacting with the Tahoma Narrows bridge.

E.g. the arms race between the USA and USSR (I believe this was modelled using agent-based modelling).

E.g. the undesired emergent property of customer service agents messing with billing data.

 

The properties that “emerge” in agent-based systems might better be called outcomes rather than properties.

 

Similar diagrams?

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?

 

Motivations?

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 behavior 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 behavior of the system over time, looking for chaotic behavior, 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 behavior 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 behavior of individual actors may be deterministic, the behavior 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     14/10/2018 20:21

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