Integration and Implementation Insights

Sharing integrated modelling practices – Part 1: Why use “patterns”?

By Sondoss Elsawah and Joseph Guillaume

1. Sondoss Elsawah (biography)
2. Joseph Guillaume (biography)

How can modellers share the tacit knowledge that accumulates over years of practice?

In this blog post we introduce the concept of patterns and make the case for why patterns are a good candidate for transmitting the ‘know-how’ knowledge about modelling practices. We address the question of how to use patterns in a second blog post.

In broad terms, a pattern links a solution to a problem and its context. As a means of externalizing understanding of practices, the concept has been used productively in various fields, including architecture, computer science, and design science. For a more general introduction to patterns, see Scott Peckham’s blog post. While a “pattern” is ultimately a simple idea, there tends to be disagreement about a precise definition. This poses a problem for this blog post.

Our aim is to communicate the usefulness of patterns for surfacing and transmitting tacit knowledge about modelling practices, but we encounter the challenges that the pattern concept can be too abstract, the audience may have preconceptions about the pattern concept, and that the audience may not have a modelling background.

As you may have guessed, we can use a pattern to try to solve this problem, namely the pattern ‘use a concrete example’, as described in the figure below. What does it mean for a pattern to link a solution to a problem and its context? In this case:

A user of this pattern should be able to assess whether the solution is applicable to their situation, and to put it in action.

integrated-modelling_patterns_sondoss
Description of the pattern: ‘Use a concrete example’

We refer to the description in the figure as a pattern artefact – an explicit description of the underlying relationship between a solution and a problem, in this case captured using a structured template. It is easy to fall into the trap at this point of confounding the pattern artefact with the pattern itself, which is why we have deliberately avoided using the headings “problem”, “solution” and “context” in this example. “What template should I use?” is a common question when identifying patterns, but the artefact itself may take many different forms. In addition to templates, like that used in this figure, the artefact could be, for example, a narrative, a diagram, or an audio recording.

To answer the question of why patterns are useful, we need to look beyond the artefact itself and understand the way of thinking that a pattern represents. Sticking to the ‘use a concrete example’ pattern, we also begin to introduce more modelling-specific examples.

Integrated modelling projects require modellers to support decision making by bringing together and communicating data and knowledge from disparate sources, including different scientific disciplines and stakeholder groups. This is described in the blog post by Hamilton and Jakeman on Ten dimensions of integration: Guidelines for modellers. Every project takes a different path, with the modeller choosing tools and processes to support both technical model development and stakeholder engagement. Moreover, the modeller needs to continuously juggle constraints arising from limited resources and other situational factors. This path dependence in modelling projects is described in the blog post by Lahtinen and colleagues.

The need for methodological versatility means that many aspects of integrated modelling remain a craft, mastered through years of experience from a wide range of projects in different contexts. Well-established theories and methodologies provide some guidance. Modellers also use their accumulated wealth of knowledge regarding the practice of integrated modelling – the reality of how modellers go about modelling.

In this welter of craft, theory, method and practice, an observer might distinguish the repeated occurrence of problems that are consistently solved using specific solutions. To take one example, each time the modeller needs to improve how the model fits observations, they use optimisation to fine-tune parameter values. In a second example, each time they need to connect existing models, they first draw a conceptual diagram of the broader system, and ask for feedback from key stakeholders. A modeller may not always be able to name what they are doing, and may even struggle to describe which aspect of the problem makes the solution appropriate. Nevertheless, they stand by their choice in those circumstances.

The two examples above, together with our figure, therefore provide three illustrations of what we consider to be “patterns”. We want to externalise these “problem-solution-context” bundles – giving them names, and beginning to unpack the reasoning behind them. Our premise is that this externalisation will ultimately lead to improved modelling practices.

The essence of the pattern is not the pattern artefact (ie., the way the pattern is described), but the mindset of isolating a specific problem and solution and focusing on the circumstances in which the solution may be effective. For our three illustrative patterns, we want to know, for example:

Each “pattern” then corresponds to an abstraction of actual practice, intended to provide an easily digested outline of what works and why. It is a way of sharing advice based on experience regarding what works in specific situations.

Patterns can be mixed with other methods for conveying knowledge:

Some will maintain that each modelling project is uniquely different, but we argue that modelling projects are different in very similar ways. We just need to look harder to see the patterns and demystify the search for solutions.

We would like to hear your thoughts about patterns. Do you find the pattern concept useful for eliciting tacit knowledge about common practices in your professional field? Do you have useful examples of patterns to share from your professional practice?

Biography: Sondoss Elsawah is a senior lecturer at the University of New South Wales, Canberra, Australia. She comes from an operations research background. Her research focuses on the development and use of multi-method approaches to support learning and decision making in complex socio-ecological and socio-technical decision problems. Application areas include natural resource management and defence capability management. Her recent work focuses on how to integrate and transfer knowledge across projects and application domains to improve the practice and teaching of systems modelling methodologies. She is member of the Core Modeling Practices pursuit funded by the National Socio-Environmental Synthesis Center (SESYNC).

Biography: Joseph Guillaume is a Postdoctoral Researcher with the Water and Development Research Group at Aalto University, Finland. He is a transdisciplinary modeller with a particular interest in uncertainty and decision support. Application areas have focused primarily on water resources, including rainfall-runoff modelling, hydro-economic modelling, ecosystem health, global water scarcity and global food security. Ongoing work involves providing a synthesis of the many ways we communicate about uncertainty, and their implications for modelling and decision support. He is member of the Core Modeling Practices pursuit funded by the National Socio-Environmental Synthesis Center (SESYNC).

This blog post is one of a series resulting from the third meeting in April 2017 of the Core Modelling Practices pursuit. This pursuit is part of the theme Building Resources for Complex, Action-Oriented Team Science funded by the National Socio-Environmental Synthesis Center (SESYNC).

Exit mobile version