System Dynamics
The short but jargon-filled definition of System Dynamics (many variants of which you will find in the literature) is ‘a computer simulation method for analysis of complex dynamic systems’. If we unpick and decode this a little, we can say it (i) is typically implemented on a computer using software to carry out the calculations we put into the model, (ii) allows us to prod and poke a model to run different scenarios and look at different outputs for comparison, and (iii) is normally used to look at systems which are dynamic or moreover have some interesting dynamic properties.
More concretely, a System Dynamics model is made up of stocks and flows, and the factors which affect flows. Stocks are any entity which accumulates or depletes over time. A flow is the rate of change in a stock (usually represented by a differential equation). Stocks take numerical values, and flows are defined by equations which can be affected by any number of other factors in the model. These equations may be relatively simple, using standard operations like addition, subtraction, multiplication, division, and sometimes exponents, or more complex involving functions and parameters which moderate how variables interact. Once a set of stocks, flows, and the factors which affect them are specified in equations, the simulation can be run by choosing a starting point (i.e. a set of stock values) and computing how stock values change through repeated time steps (i.e. through being repeatedly changed by their associated flow). Figure 8.1 shows an example of a stock and flow System Dynamics model which represents tourism and pollution in the Maldives (it is taken from Kapmeier & Gonçalves, 2018). As with most of the methods in this book, the diagram is in essence made up of boxes and arrows. Common to many System Dynamics diagrams, in Fig. 8.1 we can see the stocks as rectangles, the flows as straight hollow arrows with hourglass-type symbols (these are meant to represent valves) on them, and the factors that affect flows represented by floating text and the solid (and mostly curved) arrows. The small circular feedback arrows with italic annotations are labels for the feedback loops represented by the arrows around them. B stands for a balancing feedback loop, meaning that it will tend to self-stabilise, R for a reinforcing feedback loop, which will tend to carry on increasing or decreasing. Not so common, but used here, are the dotted lines to represent influences which were not included in calibration processes due to missing data (more on calibration later).
Fig. 8.1
A System Dynamics stock and flow diagram of pollution and tourism in the Maldives. (Source: Kapmeier and Gonçalves (2018))
Full size image
To describe some of the equations in the model, let’s take the example of the number of tourists. This is represented by the stock ‘Tourists’, which changes based on the flow ‘Change in tourists’, which is, in turn, determined by a constant historical tourist growth rate (we cannot see this in the diagram, but it is specified in text which describes the model) modified by the factor ‘Attractiveness of the Maldives’ (which we can see here). Essentially, the flow is a differential equation specifying the rate of change of tourists over time, as the historical rate of change is impacted by the changing attractiveness of the destination.
$$ \frac{dT}{dt}=T\ast {g}_h\ast \left(1+A\right) $$
where T is number of Tourists, gh is Historical Tourist Growth Rate and A is Attractiveness of the Maldives.
‘Attractiveness of the Maldives’ is calculated based on five inputs: tourist numbers, crowding, demand/supply balance of beds, prices, and tourist awareness of pollution. The ways these are specified in an equation can vary from something simple to something more nuanced. In Kapmeier and Gonçalves (2018), they are calculated with the following equations:
$$ Attractiveness={E}_R+{E}_{DS}+{E}_P+{E}_p $$
where ER = Effect of Resort Exclusivity on Resort Attractiveness; EDS = Effect of Demand/Supply Balance on Resort Attractiveness; EP = Effect of Pollution on Resort Attractiveness; Ep = Effect of Price on Resort Attractiveness
$$ {E}_R={f}_1\;\left( Tourists/ Tourists\ reference\ value\right) $$
$$ {E}_{DS}={f}_2\;\left( Required\; Bed\; Capacity/ Annual\; Bed\; Capacity\right) $$
$$ {E}_P={f}_3\;\left( Pollution/ Pollution\ reference\ value\right) $$
$$ {E}_p={f}_4\;\left( Price/ Price\ reference\ value\right) $$
where the f functions are decreasing s-shaped logistic functions, and reference values estimated from past data are used to normalise the input variables (i.e. dividing the current number of tourists by a reference value normalises it relative to that reference). The logistic functions bound the effects on attractiveness of any variable between specific upper and lower limits, ensure that increasing values of numbers of tourists, demand/supply balance, pollution, and price decrease resort attractiveness and allow the system to be set up so that a high value of any one of these factors dominates over any positive effects from others. Similar sets of equations are described for each of the stocks and flows in the map and the influences on them. These equations together allow the dynamical behaviour of the system to be simulated.
It is often assumed that System Dynamics models are deterministic using the same exact values each time and thus producing the same result every time; however, this is not true. Many models, and indeed very early examples, included stochastic elements. What types of things you can represent in stocks and flows is in theory broad. We do not have to have data on things in the model, and they don’t even have to be quantifiable. Indeed, the founding figures of the method were clear that we did not need to revert to using highly quantitative factors with data to back them up. As long as it makes some sense for stocks to be talked about going ‘up and down’ and we can put some numbers to them and factors in equations without it being completely meaningless or inappropriate, we can make a model work.
However, in practice, people often favour more quantifiable elements and avoid ‘soft’ (unquantified) factors. This is perfectly understandable; the existing literature and data make it much easier to quickly implement a biophysical factor such as ‘rainfall’, for example, compared to a social factor such as ‘Attractiveness of the Maldives’ (as above). The natural and physical sciences tend to have more data and quantitative models of almost all the factors we might ever wish to use from these domains, whereas the social sciences do not. This data and models make it easy to implement these factors (i.e. we know their values, and we know what they are affected by). We must put in extra effort and take extra care to include important social and ‘soft’ factors in our System Dynamics models. Specifying mathematically how they interact may take a great deal of careful thought. All complex adaptive systems will have these components, and they will often play important roles in dynamics, so we cannot ignore them simply because they are more difficult to specify.
Once a System Dynamics model is built, it is ‘run’, this produces outputs, such as those seen in Fig. 8.2. Here we see values for the stock ‘Tourists’, through time, under multiple different scenarios (labelled capacity, access, and price, there is also a baseline scenario and some real data plotted). A scenario represents a change in the model, either in the equations of flows or in the structure of the model (i.e. with a connection added or removed), both of which are intended to represent some intervention or difference in the system. Here the scenarios represent different policy options. Quite different sorts of system futures are visible under different scenarios. For example, increasing tourist access or capacity ultimately leads to a crash in tourist numbers as the resulting pollution from high tourist numbers destroys the destination’s attractiveness. A policy of lowering prices does not have such large impact on tourist numbers and hence does not lead to a boom-and-bust dynamic.
Fig. 8.2
Number of tourists under different policy scenarios. (Source: Kapmeier and Gonçalves (2018))
Full size image
There is ongoing debate in the System Dynamics community, and other simulation communities, as to whether we should ever (try to) interpret model outputs as predictions of future states. Many scholars contend that as the models are simplifications of reality, and the reality we are modelling is a complex adaptive system with many components and interactions, models will never be able to provide reliable predictions of future states, so we should not attempt to use them in this way. Rather, they suggest, we should consider model outputs as hypothetical futures, or qualitative forecasts of the types of patterns and dynamics we might see. However, others take an opposing view, seeing prediction as one of the main purposes of models, and while acknowledging the difficulty of prediction in complex systems, still wish to attempt to predict using models like System Dynamics, and (partially) assess the quality of models against their ability to predict. Without some element of prediction, they see models as missing a key element of what defines a ‘good’ model. We tend to sit on the fence on these debates, taking a pluralist view and seeing the merit in both approaches. As we have often said in this book, purpose drives the model. If our purpose is to predict, and we have designed with this in mind, it is not beyond the reach of methods like System Dynamics, but it is certainly very difficult, and success may well be fleeting.
As with many quantitative modelling methods, there are a range of rather technical activities that will be part of any System Dynamics process, which include parameterisation, calibration, validation, and sensitivity analysis. In practice, these elements often merge into one another, and the exact nature of how they are done, in what order and combination, and their importance in the modelling process, will depend on the purpose of each modelling project. We do not wish to go into the gory details of how they are done, which is beyond the scope of this chapter, but briefly, here are some simple (yet still debatable) definitions of them: parameterisation is the process of picking values for parameters (e.g. stocks, factors, equations, modifying flows) in the model based on data or plausible values (i.e. ‘plausible’ is a loose idea, but here we mean values which an expert on the system would deem sensible); calibration is the process of picking values for parameters such that the model produces outputs that reproduce some target (e.g. changing values until the model produces a pattern seen in real data); validation is the process of assessing how well the model reproduces target outputs (and often involves elements of calibration); and sensitivity analysis is where different parameters, or structural components of the model (e.g. which connections and relationships are represented), are changed systematically to assess how sensitive model outputs are to them. Each of these activities can be done in informal qualitative ways, or in much more technically demanding quantitative ways.
There are some important variations in practice and terminology in System Dynamics. In the practice of System Dynamics modelling, these mostly revolve around how we arrive at a fully specified and quantified stock and flow diagram. Some system dynamicists dive straight into a stock and flow diagram, whereas others first produce Causal Loop Diagrams (see Chap. 4) or other similar types of qualitative or semi-quantitative systems maps. These differences in where to start will likely have impacts on the models produced. Causal Loop Diagrams are a point of variation in terminology too. We have observed Causal Loop Diagrams referred to widely as ‘system maps’. The way they are built appears to be consistent, but the different terminology can be confusing and unhelpful when the term ‘system maps’ also describes a variety of approaches, as we outline in this book. We have also seen stock and flow diagrams referred to as Causal Loop Diagrams and vice versa, though their intended use is normally clear.
Before we move on to how to do System Dynamics, we would like to emphasise one element in the method that is different to some of the others in this book but is not immediately obvious. Despite having ‘system’ in the name, System Dynamics models tend to be focused on specific dynamical problems rather than whole systems. In practice, this means that models rarely aim to represent a whole system, but rather focus on carefully constrained sub-sets of a system with the relevant dynamics. This nuance in focus is often not understood, with many researchers and practitioners envisaging System Dynamics as taking a whole-systems view, where in fact it is the ‘dynamics’ that the method emphasises. Indeed, part of the ‘art’ of System Dynamics modelling is finding and defining these knotty dynamical questions and problems which the method can contribute to significantly.