Sharing integrated modelling practices – Part 2: How to use “patterns”?

Community member post by Sondoss Elsawah and Joseph Guillaume

sondoss-elsawah
Sondoss Elsawah (biography)

In part 1 of our blog posts on why use patterns, we argued for making unstated, tacit knowledge about integrated modelling practices explicit by identifying patterns, which link solutions to specific problems and their context. We emphasised the importance of differentiating the underlying concept of a pattern and a pattern artefact – the specific form in which the pattern is explicitly described.

joseph-guillaume
Joseph Guillaume (biography)

In order to actually use patterns to communicate about practices, the artefact takes on greater importance: what form could artefacts describing the patterns take, and what mechanisms and platforms are needed to first create, and then share, maintain, and update these artefacts?

While the concepts of ‘problem, solution and context’ should be discussed in some way, there is no single best way of representing patterns as artefacts. The form of artefacts will differ depending on many factors, including how the users perceive the ease of:

  • absorbing the pattern
  • understanding relationships among patterns
  • discovering or being made aware of patterns
  • eliciting contributions and building group understanding.

Absorbing the pattern

Patterns are intended to be easily absorbed. The most common ways for representing patterns are structured templates and graphical description (mostly Unified Modelling Language (UML)). In part 1 of our blog posts, we documented the ‘Use a concrete example’ pattern using a structured template artefact consisting of the elements: Pattern name, Context, Description, Consequences, Related patterns.

Understanding relationships among patterns

In order to capture relationships among patterns, patterns are commonly organised into collections in one of two ways. First, patterns may link to each other in their descriptions, such that they organically form an interlinked collection, referred to as a “pattern language.” For example, a modelling pattern describing parameter estimation might link to patterns involving optimisation, selection of objective function, and addressing parameter uncertainty. If relationships are defined by users, the structure of the collection emerges from their needs. This can be an efficient and effective way of progressing patterns, especially in initial design cycles when building understanding and consensus about integrated modelling patterns is only starting.

Alternatively, patterns might be classified more formally to give the community an accessible and easy-to-navigate intellectual repository of existing patterns. The classification gives a big picture overview, as well as giving newcomers a jump-start. For example, modelling patterns might be divided by the stage of the modelling process in which they are used, eg., stakeholder feedback on a conceptual model might belong to a “planning” stage, and parameter estimation to a “model construction” stage. Such a pre-defined structure requires a well-developed shared understanding of relationships among patterns, and may result in substantial changes to the structure if new patterns are added.

Discovering or being made aware of patterns

To assist users in discovering or being made aware of patterns, they can be collected in handbooks, textbooks, journal articles, pattern repository websites, blogs and collaborative wiki.

Eliciting contributions and building group understanding

Eliciting and conceptualizing tacit knowledge is intrinsically challenging, both in obtaining knowledge from individuals and building a group understanding. The philosopher Polanyi (1967) described tacit knowledge as “knowing more than we can tell”, or “knowing to do something without thinking”. The more experienced the person is, the more this knowledge becomes ingrained into their hard-to-access mental schema and becomes taken for granted or regarded as common-sense.

Our anecdotal experience suggests that pattern thinking can be promoted by looking for distinct solutions within a narrative, targeting questions regarding what problem the solution was intended to solve, as well as trying to identify changes to context that would have resulted in switching to different practices.

Building a group understanding involves obtaining agreement. Participants may differ in their perspectives on:

  • what worked or did not work in a project, in other words conceptualisations of the solution being discussed,
  • factors affecting success,
  • how best to capture and represent the lessons learned, and
  • how the relationship between different solutions should be presented for effective communication.

Conclusion

Developing and using patterns is an ongoing process of building a shared vision of problems, solutions, and context. The pattern approach is a bottom-up process, initiated and sustained by members of a community, with similar objectives, addressing similar problems. Greater experience within the community will improve the ability of community members to reach shared understanding, and lead to greater benefits from a pattern-based approach.

The integrated environmental modelling community lags behind other domains, such as engineering and computer science, in capturing modelling experience from tacit knowledge. We believe it is worth pursuing a pattern-based approach for learning about modelling practices, and we need to develop sustainable mechanisms (including funding) to identify, share and maintain the pattern artefacts.

We welcome your thoughts regarding how we can move forward with patterns in eliciting tacit knowledge about modelling practices.

Reference:
Polanyi, M. (1967). The Tacit Dimension. Doubleday: New York, United States of America.

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

5 thoughts on “Sharing integrated modelling practices – Part 2: How to use “patterns”?

  1. This comment by Len Malczynski was reproduced from the Linked In System Dynamics group:
    Can there be patterns of practice in the sense of how you start the construction of models? This is quite different from eliciting information about a problem. There are mechanics that aid in producing a well functioning model.

    • Thanks, Len for the spot on comment. Definitely, there should be patterns of practices about how you start the model construction. There should be ‘patterns of practices’ about every practice the modeller does through the process. At the moment, we are working on a project for capturing ‘patterns of practice’, and our starting effort was to identify the detailed steps of a modelling process, and the questions that the modeller needs to address at every step. Then, we used these questions to tease out the patterns of practice. Any patterns to share from your experience re starting the model construction, or any other activity in the modelling process?

  2. This question by Martin Shaffernicht was reproduced from the Linked In group System Dynamics:

    When you say”patterns”, do you refer to typical structures which can be selected and then adapted to a specific case? If this is the case, then it reminds me three concepts which have been proposed and discussed at different times in the SD community. There were “generic structures” (and “archetypes”) which had quite a discussion during the ’90 and early 2000; also, during the same period, “Molecules” were developed for the Vensim software. I guess that from the time when John Sterman’s “Business dynamics” textbook came out (2000), the concept of “standard formulations” has taken the place of “generic structures”. Quickly stated, “generic structure” was debated because it seems to make an ontic claim that such structures “really” exist. If you say “standard formulation”, no such claim is made – it is just a (model) formulation. But it is “standard”: tested and trustable, well understood by many modelers.

    I also think that the “family member test” in validation refers to this topic, because it requires the modeler to ask themselves if the particular situation they are modeling is not one particular instance of a class (“family”) of situations.

    Finally: one may say that classical SD models (urban dynamics or market growth, for instance) have many of the characteristics of a “stylized problem” or “pattern”, if you will. Something similar may be said of the sequence of models behind “World dynamics” and “Limits to growth”.

    So I’d say that there are some “patterns” for the minds of SD modelers. many of them have been used in the user manuals of the typical software packages, and all SD-books I know use many of them. To the exception of the “molecules”, I believe the software packages themselves have not yet integrated such pre-designed formulations.
    I believe it is a very interesting question to ask ourselves to which degree our minds are preformatted by “standard formulations” and at the same time we strive to approach each new situation as a “universe of 1”. This might be a necessary thing, since we want to take our clients along, want them to reach insights (and we cannot assume them to know our “standard formulations”).

    Personally, I’d enjoy a library of “patterns” when I’m modeling on my own or with other SDlers – this would be quite efficient. But at the same time, when I model with non-SD-people, I model-as-I-talk, and therefore I would not use “patterns” in a session. This helps the other individuals to experience modeling as kind of a disciplined conversation.

    • Thanks for the comprehensive comment. The concept pattern is very flexible and can be used to represent many things and for different purposes. Patterns, as used in software engineering and SD literature, are used to represent frequently used formulations (exactly as you explain them). They are often implemented into libraries (some of which are embedded in standard SD software), and some of them are developed by modellers and developers to reduce rework in their projects. The purpose of using patterns in this case is reusability, and improved efficiency. In regard to the specific use of a ‘pattern artefact’ (as described in our first blog post) in the SD literature, Hines used the pattern template (problem, description, context, solution) to document the molecules.

      In these blog posts, we advocate the use of patterns to represent modelling practices (not the model’s structure or formulations). The purpose is to share the knowledge and experience of experienced modellers. For example, in your comment, at the end, you have shared a useful pattern from your experience regarding a practice that you usually use in your modelling process. The patterns relate to whether to use your ready-developed and tested SD modules or model from scratch. You also gave us a brief insight into when you use what (i.e. dealing with experienced modellers vs in-experienced users who would like to experience the discipline of modelling). Would not be very valuable (for learning, and education) if we can capture these practices in a form of explicit patterns of when to use what practice and why? This is what we are advocating for in these blog posts: the use of patterns to elicit and formulate modelling practices with the purpose of knowledge sharing and learning.

      Any other patterns from your experience to share with us?

  3. Discussion copied from the Linked In group Design Thinking
    Steven Forth asked: Do you see a role for patterns in design thinking?
    Sondoss Elsawah responded:
    Thanks for the interesting question. Design thinking and the patterns approach are very closely linked. First, the process of mining and evaluating patterns is usually represented as a design science research activity, with the aim of creating an artefact (i.e. patterns) to communicate about the state-of-practice. Two references are below:
    (1) On the use of a design thinking approach for patterns development: Vaishnavi, Vijay K., and William Kuechler, Jr. 2007. Design Science Research Methods and Patterns: Innovating Information and Communication Technology. Auerbach Publications, http://www.crcnetbase.com/doi/book/10.1201/9781420059335
    (2) On the use of a design thinking approach for patterns evaluation: Petter, S., Khazanchi, D., & Murphy, J. D. (2010). A design science based evaluation framework for patterns. ACM SIGMIS Database, 41(3), 9-26.

    The second link between design thinking and patterns, is the use of the patterns approach to elicit design practices. Design is a craft that is mastered through experience, and experienced designers have their palette of patterns. There are already patterns identified in design thinking, which range from generic to specific for the development of a particular type of artefact. The ‘Russian dolls’ pattern is an example of a generic pattern used to describe how a designer explore the design space in a form of decision tree exploration – with decisions leading to partial solutions at each node of the tree. More specific patterns have been identified for the development of software interface. In his book, Tidwell (2010) presents a useful collection on the design of interfaces, and compiles some pattern artefacts represented in the form of (when, why, how) template.
    I wonder if you have any thoughts re the possible role of the use of patterns in design thinking or useful example to share.

    Tidwell, J. (2010). Designing interfaces: Patterns for effective interaction design. ” O’Reilly Media, Inc.”.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s