Let’s be honest, systems mapping means lots of different things; it is broad and ill-defined. We are not going to ‘fix’ that here (if we even think it needs fixing). We support inclusive and broad definitions in general, and think they are inevitable when it comes to systems mapping. But that breadth and inclusivity should not come at the cost of clarity. We still need to know where we are at, and what is on either side of us.
In time-honoured academic fashion, let’s start by breaking this down into its component parts, and first asking what is a ‘system’? There is no simple answer to this question. We regularly see arguments about whether something is a system or not, whether a system mapping exercise has taken enough care thinking about what the system it is mapping, or even whether we should be mapping problems not systems at all. While these concerns are important, it is possible to define almost anything as a system with enough mental gymnastics. Moreover, what the ‘right’ system definition for you is will always be context dependent. This means we would rather proceed with thinking about what your system is, rather than dwelling on what a system is. Your system might be the system you are part of, and you wish to understand, or the system which you are going to map, hopefully with some purpose in mind.
Nonetheless, given that others have considered what a system is, it’s worth looking at a couple of our favourite definitions. Williams and Hummelbrunner (2011) suggest that there are a few distinctions we can all agree on: (i) that systems are made up of some set of elements; (ii) that systems also constitute the links between elements, whether they are processes or interrelationships; and (iii) that systems have some boundary, and this is central to their definition. They accept, as we do, that this set of distinctions could mean almost anything, so they suggest focusing on what is distinctive about seeing the world with a systems lens, rather than dwelling on definitions.
Meadows (2008) takes this definition one step further, bringing in the ideas of purpose and organisation, suggesting a system is an ‘interconnected set of elements that is coherently organised in a way that achieves something’ (pg. 11). The idea of a system purpose, and using it to help define your system, and perhaps your mapping exercise, is useful but slippery. It will likely require you to have a broad definition of a purpose, to include functions, services, or value that a system may provide.
The second component of ‘systems mapping’ is ‘mapping’. So, what is a ‘map’? Here we bump into an unfortunate historical quirk of terminology. In the systems mapping world, ‘map’ is used synonymously with ‘model’. They are both reasonably intuitive words, but there has been a lot of thought about what a model is, and separately, what a map is, some of which has ideas in common, but plenty which does not. Maps are normally thought of in the cartographic, geographic sense, a representation of a physical space. There is fascinating literature on considering what these types of maps are and how they shape our thinking. Some of this is useful when thinking about models and system maps, but some of it is a distraction.
More useful, we think, is the history of thought on modelling and, within this, asking ‘what is a model?’ As with systems, there are many definitions and types of model, but there is a little more consistency and a settled general definition. We would characterise this definition as this: a model is a purposeful simplification of some aspect or perception of reality. ‘All models are wrong, but some are useful’ (Box and Draper, 1987) is the modelling cliché to end all modelling clichés, but it is instructive. The simplifications a model makes in its representation of reality mean it is inherently ‘wrong’ (i.e. it is not reality), but if these simplifications serve some purpose, then there is a decent chance that they are useful.
So now we know what a system is, and what a map is. Do we know what a system map is? Not quite. We should stop talking in the abstract and show you with examples, but first we need to introduce a few common components of systems maps:
-
Network: in its simplest sense, a network is a set of boxes connected by lines. In system maps, these lines are often directed, that is, they are arrows from one box to another.
-
Nodes: the ‘boxes’ in a network are normally referred to as nodes.
-
Edges: the connections, lines, or arrows between boxes are normally referred to as edges.
All except one of the methods in this book always have a network of nodes and edges, representing cause and influence between factors in a system, at their core. These networks of cause and influence are the model (i.e. the map) of the system.