System Dynamics

Modelling a continuously varying system

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 21/02/2018 23:05

                                                                 

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

It is also the second of three papers on the dynamic behavior of systems you can find on this system theory page.

Contents

Dynamics. 1

Forrester: System Dynamics. 2

Proving and using a model 4

Meadows: System Dynamics. 4

Abstractions of quantities from qualities. 6

System dynamics methodology. 9

Commentary on system dynamics modelling. 13

System dynamics in EA?. 14

Conclusions, remarks and links. 16

 

Dynamics

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

 

Discrete (or digital) system state change

This means that a system’s state advances incrementally in response to discrete events.

The term digital is used to describe signals that are chunked into discrete units, as in a clock that displays the time as numbers. 

Most business systems are driven by discrete events and experience discrete state changes.

So they are modelled as what is called discrete event-driven systems (DEDS).

 

E.g. A business monitors and directs entities and events in its environment.

The entities’ state variables are recorded in a database.

The events are represented as transactions applied to that database.

The system runs in a feedback loop with its environment.

It detects events and changes in the environment.

It maintains a model of the entities and events that it monitors.

It sends messages to direct entities and events in the real world.

A transaction processing system enables current business operations, but does not predict their long-term outcomes.

 

Continuous (or analogue) system state change

This means that a system’s state advances continually in response to continuous forces or inputs

The term analogue is used to describe signals that vary continuously, as in a clock with revolving hands.

However, continuous systems can be modelled as discrete event-driven systems.

“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

 

Forrester: System Dynamics

System Dynamics is an agent-based (or agent-oriented) system simulation method.

The system of interest is modelled as a closed system of stocks related to each other by flows.

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

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?

The long term outcome of a system (at the macro-level) is not predictable from knowledge of the system’s roles and rules.

It is sometimes possible to mimic or predict the outcome 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 happens to system state variable values (stock quantities) 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?).

 

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

 

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.

The individuals change: sheep come and go; wolves come and go.
What remains stable is only the roles they play in the described system.

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 or amplifying loops

Some balancing feedback loops act to keep a system stable.

Sometimes the long-term result 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 system can continually expand or grow in some way: E.g. A business increases its revenue every year.

Proving and using a model

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

1.      A real-world or operational system.

2.      A static system description - a design-time model – which is a theory of 1.

3.      A dynamic system description – a run-time model - which simulates 1.

 

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

Building the model and running it can be seductive; it does not prove that it is a good model of reality.

Until tested against reality, the model remains a theory.

 

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

The model should make sense of historical data and/or predict future system states.

You may have omitted entities/stocks or events/flows that turn out to be important to your interest.

If the model’s behavior does not match reality, then you can try to modify the model until it does.
You can change anything – the stocks, the flows, the initial conditions, the rules.

 

Some use System Dynamics software tools in an attempt to predict the long-term outcome of real-world behaviors.

A System Dynamics model declares a theory of how the world works; proving the model is a correct is another matter.

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

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.

 

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

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

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

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

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

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

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

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

 

Meadows explained the concrete elements may come and go, but their behaviors stay the same.

"A system generally goes on being itself, changing slowly if at all, even with complete substitutions of its elements." Meadows

 

The primacy of behavior (again)

The idea that a system is a set of roles and rules, rather than a particular set of actors, is a general system theory concept.

“The principal heuristic innovation of the systems approach is what may be called ‘reduction to dynamics’ as contrasted with ‘reduction to components’ ” Laszlo and Krippner.

The system does not depend on any individual actor to perform a behavior, since one actor can be replaced by another.

 

The principle was expressed by Meadows thus:

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

By characteristics she meant the system’s regular repeatable behaviors, and the results they lead to.

 

Meadows regarded abstract system behaviors to be (usually) more important than concrete system structures.

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

 

Individual actors (let alone their hopes and fears) do not appear in a System Dynamics model.

Actors are merely items in a stock quantity.

The roles they 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.

 

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

"Changing relationships usually changes system behavior.” Meadows

"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

Meadows presents the long-term results 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 results 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 might 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 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.

 

System dynamics models as soft systems

A System Dynamics model of the world is an abstract system, a soft system.
It is only one narrow perspective of what happens in the world.

Many systems thinkers fudge the distinction between system descriptions and physical realizations of them.

Ashby was keen we separate them.

Abstractions of quantities from qualities

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.

 

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 or chaotic outcomes in the long run.

Agent-oriented 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.

 

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)

 

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.

 

Abstracting System Dynamics model from a Discrete Event-Driven model

You can convert a discrete event-driven model into a System Dynamics model by abstraction.

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.

 

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

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

 

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)

 

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.      Define the time steps

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

4.      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 a given unit of time.

·         Define any flow rates that will be defined when initialising the model.

5.      Initialise the model

·         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

6.      Run the model

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

7.      Review the results and refine 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 (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

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

 

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

 

5 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 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

 

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

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

 

7 Review the results and refine the model (repeat)

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

Building the model and running it can be seductive; it does not prove that it is a good model of reality.

Until tested against reality, the model remains a theory.

 

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

The model should make sense of historical data and/or predict future system states.

You may have omitted entities/stocks or events/flows that turn out to be important to your interest.

If the model’s behavior does not match reality, then you can try to modify the model until it does.
You can change anything – the stocks, the flows, the initial conditions, the rules.

 

Some use System Dynamics software tools in an attempt to predict the long-term outcome of real-world behaviors.

A System Dynamics model declares a theory of how the world works; proving the model is a correct is another matter.

And if you don’t like the predicted outcome, the cost-benefit case for changing real-world behaviours 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.

 

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

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

 

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

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

Meaning that individual agents, following simple behavioral rules at a micro level, can generate “complex behavior” at a macro level.

However, these are not properties in conventional sense, and the term “complex behavior” is misleading.

If there is complexity, it is in the trajectory followed by state variable values (stock levels) over time.

 

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-oriented 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     21/02/2018 23:05

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