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:

  • the solution is described in the sections ‘Pattern name’ and ‘Description’, which provide sufficient detail to understand how it should be implemented
  • the problem addressed is expressed as the ‘Objective’ and intended ‘Consequences’ of using the solution
  • the context (see the section ‘Context’) describes the circumstances in which the solution is an effective means of addressing the problem, with ‘Related patterns’ linking to other patterns that might be used in a similar context.

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

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:

  • Under what conditions will using a concrete example actually be effective?
  • What are the steps taken to present a concrete example in an effective way?
  • In what circumstances is parameter estimation appropriate?
  • Are there circumstances when requesting feedback on an integrated conceptual model is not necessary?

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:

  • Their emphasis on solutions and problem context can be further illustrated with case studies.
  • Methods and methodologies can provide formal descriptions of the steps involved in implementing a solution, describing, for example, how parameter estimation can be undertaken.
  • Building consensus around specific solutions can turn them into best practice guidelines—for example, advocating the use of stakeholder consultation—while recognising that there may be contexts in which the guidelines do not apply.

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

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

  1. This example highlights but does not acknowledge the main unfortunate outcome of using patterns — it does not include any act to confirm a) whether the pattern was accurately understood and properly applied and b) whether the pattern actually leads to a viable solution to ‘the problem.’
    In most cases a pattern is used in lieu of careful thinking. This enables the pattern author but threatens any pattern user.
    OBTW, does the reader recognize the above as a pattern regarding the pathology of patterns?

    • For patterns, similar to any thinking approaches and artefacts, there is an inevitable question about realising actual cognitive change and if this change is translated into behavior change in relation to the practice. There is definitely a need for experimental research to investigate the effects of using patterns on people’s understanding and practice. An example is below
      Moskaliuk, Johannes, Franziska Bokhorst, and Ulrike Cress. “Learning from others’ experiences: How patterns foster interpersonal transfer of knowledge-in-use.” Computers in Human Behavior 55 (2016): 69-75.
      Do you have any thoughts regarding how to include this into the pattern example?

    • I would add that this is an issue with all kinds of scientific methods, and the ‘blackboxing’ of science generally. Applying methods or insights inadequately or out of context is a major challenge, and the more general concept of a pattern faces the same issue. Pattern artefacts can also benefit from testing and peer review. The concept of a pattern additionally requires that any practice, method or insight should explicitly lay out the context in which it is intended to be used. Would you agree that’s something worth promoting?


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.