2.7 COMMUNICATING IDEAS ABOUT DYNAMIC HYPOTHESES
Effective and efficient modelling entails having detailed understanding of feedback dynamics and commensurate skills in rapid visualisation and communication. I proffer that communicating ideas about dynamic hypotheses is enabled through the use of these building blocks. This makes these building blocks essential. Communicating through the use of precise language supported by these building blocks is a highly effective way of making ideas and hypotheses about dynamic behaviour very explicit. Unlike the use of language such as we see in causal loop diagrams (and to a lesser extent influence diagrams) the use of system dynamics modules as tools for communication is precise and open to little interpretation. I believe this is what Barry Richmond was attempting to create when he repeatedly advocated the development of conversational system dynamics for use by teachers, practitioners, and researchers.
During my research, I have discovered (and perhaps it should come as no surprise) that certain system dynamics modelling building blocks frequently appeared: the most astute researchers recognised this well before I did. Development of a compendium of fully specified system dynamics modelling building blocks has been surprisingly slow. It seems that all such initiatives have been confounded by teaching practices in system dynamics modelling that too frequently lead to the creation of fully ‘hooked-up’ or ‘wired-up’ models with connections between parts of the model fixed and in place. These ‘completed’ models are not always seen by the modeller, teacher or client for what they are; that is, an assembly of small, highly functional, re-usable competent parts. The notion of re-use of components is familiar in systems engineering and software development disciplines, but not so familiar in system dynamics modelling. System dynamics modellers could do well to learn from these related disciplines by investigating the opportunities for component or module re-use.
The term module is used in software development to identify specific blocks of code, which perform sets of clearly defined functions. In operational software, one module is called by another module each time a particular calculation is to be made or an operation is to be performed. Other modules are called on an as-required basis.
Taking a modular approach in building software is essential to assuring that all necessary operations are accommodated by the design and can be performed, that is, all the required functions are available to be performed. Further, when it comes to de-bugging or resolving contention issues, where a module conflicts with another, the modules have to be small enough to be analysed in detail. Without this, the chance that errors will be detected is low. Small modules are essential to our understanding and building of code and complete models that actually work as we intend. Without this modular approach it is easy to get bogged down in the mass of detail; so it is with system dynamics models.
In addition, the connections between the component parts of models contribute to what we understand in system dynamics modelling as structure. Structure is critically important. Jay W. Forrester observed in his pioneering work in the 1960s, that structure underlies systemic behaviour. So, it follows that if we build models that result from the careful assembling of building block modules, it should then be easier to identify both structure and how the component parts and the linkages between them contribute to that structure.
The first aim here is to foster application and development of our human recognition skills. The second aim is to extend these to enable the design of highly functional system dynamics models. Being able to identify reliably and quickly the important structures and how those structures are built by assembling the building blocks together will help us to be more effective in our modelling efforts. This will also help reduce non-productive periods and free up our minds for highly creative modelling, critical thinking and analytical activities.
The modular approach also helps us identify the natural functional boundaries we might draw around parts of a model. In effect we become more focused on those parts of systemic problems that contribute most to the dynamic behaviour in the real world.
In systems engineering, considerable effort is put into specifying, analysing and managing the interfaces between functional blocks or elements. We must apply the same approach because the nature of connections at these interfaces and the ‘flows’ across interfaces is always critically important. In complex systems, many design and management problems occur as a result of not fully appreciating what happens at the inter-modular interfaces.
By clearly specifying and managing the interfaces and the flows across each and every interface, whether material flows or information flows, we reduce the likelihood of errors and mismatches between component parts. So it is for the modules in the models we build in system dynamics modelling.
Despite this evidence, students, ‘experienced’ practitioners, and many teachers build models containing several levels (stocks), numerous rate-controlling auxiliaries in a fully connected, hooked-up or wired-up configuration before setting out to debug or verify the model. It is hardly surprising that these models cannot be made to work as intended without first encountering considerable difficulty.
As an aid to model conceptualisation, it is frequently necessary to hypothesise what the completed model will look like. But before attempting to create a detailed design of the model, it is absolutely essential to break the conceptual model down to an assemblage of functional component parts. A number of these component parts will correspond exactly to modules described in this book. The main differences will lie in the connection between parts and most frequently they will be in the form of information exchanges, some of which will be parts of feedback loops.