System Dynamics

Modelling a continuously varying system

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 03/04/2018 20:09

                                                                 

This paper looks at general system theory concepts through the lens of System Dynamics and vice-versa

It addresses the difference between system state change and system generation change.

And the difference between complexity in system state, in behaviors and in the trajectory of system change over time.

It is one of many related papers you can find on this system theory page.

Contents

Dynamics. 1

Forrester: System Dynamics. 2

Meadows: System Dynamics. 5

Proving and using a model 7

Animations of agent-based models. 7

Abstractions of quantities from qualities. 8

A system dynamics methodology. 10

Commentary on system dynamics modelling. 14

System dynamics in EA?. 15

Conclusions, remarks and links. 17

 

The generality of system ideas

In “General System theory: Foundations, Development, Applications” (1968), Ludwig von Bertalanffy wrote:

“There exist models, principles, and laws that apply to generalized systems or their subclasses,

irrespective of their particular kind, the nature of their component elements.” Bertalanffy

 

What do systems, in different domains of knowledge, have in common?

Some say a system is "an entity that contains interrelated things" or “a whole, separable from its environment, and composed of interrelated parts”.

However, that definition applies to passive structures.

E.g. a garden fence, a telephone directory, a necklace, or the Dewey decimal system.

In fact, it applies to most if not all things in the universe you can point to and name.

 

The term system is overloaded with different meanings.

It can refer to a passive structure of connected things and/or an abstract system description.

It usually means a concrete activity system, composed of actors interacting in the activities that characterise the system.

Read System theory ideas for more about systems in general; read on for more about System Dynamics in particular.

Dynamics

The dynamics of a system are how its state changes over time.

 

Homeostatic v progressive state change

Actors may act to maintain a system’s state homeostatically.

This means maintaining the system in a stable or viable state, through input/output feedback loops.

Alternatively, actors may act to advance the state progressively, as in most information systems.

 

Continuous (analogue) v discrete (digital) state change

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

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

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

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

 

Most business systems depend on event-driven processes that run from start to end.

A business process (short or long) is designed to produce a result or output of value to some party.

System architects model such systems using languages like UML, ArchiMate or BPMN.

 

Feedback loops

A business must monitor and direct the state of the entities and processes it cares about.

And so, it runs in a feedback loop with its environment.

It receives an input event carrying new information about business entities and processes.

It refers to information holding the last-recorded state of those entities and processes.

Depending on the state, it “chooses” what actions to take.

It may update the recorded information and/or send messages to direct entities and processes

 

The system’s behavior in response to each event may be predictable.

However, the long-term outcomes of processing many events are not.

The trajectory of state changes over time may be unpredictably non-linear or chaotic.

 

Modelling 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

 

Q: Is a system dynamics model discrete or continuous?

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.

Forrester: System Dynamics

Forrester considered every system to be set of quantities that are related to each other.

Wherever a change to one quantity has an effect on another quantity, the relationship can be seen 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 amplify or dampen changes in stock levels.

 

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.

 

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 a real world that follows the rules of the system dynamics model (e.g. will the sheep population crash to zero?).

 

Observations: some say complexity “emerges” at the macro level from simplicity at the micro level.

They say that individual actors, following simple behavioral rules, generate “complex behavior” at a macro level.

However, this is to confuse two of many ways to measure complexity.

There is complexity in the structure of system state - as in Ashby’s measure of “variety”.

There is complexity in behavior - as in Mcabe’s measure of procedural complexity.

There is complexity in the trajectory of system state change – which is an interest in System Dynamics.

 

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.

 

Balancing or 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:

A system is: “A set of elements ... that produces a characteristic set of behaviors."
And 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 and 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.

Meadows: System Dynamics

In "Thinking in Systems – A Primer" Donella H. Meadows began by explained the principles of System Dynamics.

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 of a system is what repetition of its behaviors over time results in (implicit).

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.

 

Meadows definition of a system

Meadows characterised a system by its behaviors and their outcomes.

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

 

The definition reflects the behavior-orientation in both System Dynamics and the work this paper is a part of.

In a wider discussion, some apply the term system to passive structures.

 

The definition reflects Meadows' reverse-engineering of aims from outcomes.

In a wider discussion, others separate aims from outcomes, and measure outcomes against declared aims.

 

The phrase "coherently organised" might be read to imply intent.

In this work, naturally evolved systems (e.g. the solar system) are not considered to be purposive, purposeful or organised by intent.

 

In System Dynamics, there can be three systems.

1.      A passive structure: a static system model, expressed in a causal loop diagram.

2.      An active software system: a dynamic model of stocks and flows, running in a computer.

3.      A concrete reality that 1 and 2 supposedly represent.

 

Suppose you believe 3 matches 1 and 2.

If you observe a reality that cyclically repeats its behaviours as modelled in 2, then you can meaningfully call it a system with reference to 1 and 2.

But if you observe its behavior departs from that of 2, then to call it “a system” would be an empty assertion.

(As meaningless as saying IBM is a system with no description in mind or evidence that it behaves as described.)

 

The transience of actors

Meadows said the system 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.

Actors only count as items in a stock quantity.

 

The persistence of roles and ules

The roles actors play in modifying structural variables appear in the rules of inter-stock flows.

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

The system repeats forever, unless it is stopped, it crashes, or it is changed by design to a new system.

So, what defines Meadow’s system is the roles actors play, and the rules that govern their interaction or relationships.

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

 

Reverse engineering aims from outcomes

A natural system evolves without any intent; its outcomes (e.g. homeostasis) are effects rather than aims.

By contrast, a designed system is created by intent; which implies testing its outcomes against pre-defined aims.

 

Coming at this from a different perspective, Meadows treats the long-term outcomes of behaviors as their aims.

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

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

In effect, she reverse engineers aims from observing the outcomes of repeating the same behaviors over the long term.

 

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

 

From system theorist to socio-cultural essayists

Like Russell Ackoff, Meadows started perfectly in line with 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 one 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     03/04/2018 20:09

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