By Sondoss Elsawah and Joseph Guillaume
2. Joseph Guillaume (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.
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).
Hello, thanks for these two posts. I’ll respond here, even if I address more of part 1, because the topic comes in the comments here too.
I recognize the view of patterns of Christopher Alexander and what the software community has built with it in these two posts. I will be going to the PLOP* conference in Vancouver in two weeks, maybe some in this group will be going too? The software community has done a great job to capture practices.
I think the issue of the ‘simplicity’ of the concept of pattern and the ‘disagreement about a precise definition’ is key here. I think that the discrepancy between the pattern as a recurrent structure or dynamic observed, discovered etc such as described in Scott Peckham’s post… and the pattern as problem/solution ‘system’ to render a practice, as described here and by the pattern language community may hinder our capacity to reap the whole potential of patterns, because we may be talking of patterns that are not of the same nature? I have been struggling with this for a while…
I am wondering whether coupling a problem with a solution under the denomination of pattern doesn’t somewhat deprive us from the possibility to look at patterns that are current in a context or situation and need to change (an existing behavior A), at patterns we would like to generate (a goal behavior B) and patterns of action or design (the solution or recipe to get from A to B) to get there. In particular, it may deprive us from the possibility to monitor how patterns ‘evolve’ from A to B. Problems may evolve once solutions are applied, and over-applying solutions may generate other types of problems, so a problem solution is not immutable. To me the problem (or ‘forces at play’), the solution and the outcome can all be seen as patterns. There could be ways to express a problem solution system as a system of nested or interrelated patterns.
The paradox is that most of the theory behind Alexander’s work is about configuration and generative process, while the output is pattern language presented as problem solution combinable units. So the two are employed in the discourse.
Patterns are ubiquitous and versatile, play a great role in cognitive processes, and have a kind of fractality that can be put to work, especially in light of the discussion on analogy on Christian Schunn’s post. I am conscious that I am much more focused here on the problem to model (including worldviews etc etc), than on modeling as a practice.
I would welcome any thoughts on how we could get out of this seeming incommensurability so that we can operationalize patterns the best way.
*Editor: PLoP is the International Conference on Pattern Languages of Programs
These issues have definitely come up in our discussions as part of our SESYNC pursuit. Here’s the way I see it:
– There are fundamental differences between splitters and lumpers. Taking your definition that a “pattern is a shareable unit of meaning-making which can play the role of boundary object”, some people want the unit to be quite abstract, others want it to refer to something very specific. Patterns in a generic sense vs (design) patterns describing practices are just one example. The choice of terminology is certainly confusing, but I think with further reflection it is fairly unambiguous that they are closely related but separate concepts.
– Personally, I find the generic idea of a pattern difficult to operationalise. We see patterns everywhere, but it’s unclear what to do with them. Focussing on patterns that connect problem and context to action is a more promising avenue in my opinion.
– Within a pattern language specifically, I think fractality is the solution. A good pattern language should describe patterns that suit both splitters and lumpers, making explicit the link between their perspectives, grouping specific units together into useful more abstract units. In my opinion, the advantage of using a pattern language and not just a catalog is that it uses patterns endogeneously to describe the nested and inter-related nature of other patterns, rather than forcing patterns into a separate typology, or just listing them without connection.
– If a pattern is a shareable unit of meaning-making, then the means of discovering that unit is important. (Design) patterns should not just be discoverable by the name of the solution, by leafing through a book, or by someone referring you to it. They should be linked to from other patterns, and also suggested as a response to specific contextual and problem attributes/situations. This of course agrees with your perspective that the elements of a (design) pattern are themselves (generic) patterns.
– Naming is a a key part of design patterns, but not necessarily of generic patterns. A design pattern is named after the solution it focuses on (which has also caused confusion in our discussions), and it is useful to be able to name the solution we used for any problem. However, you don’t necessarily want to give a name to every slightly different context and problem. Describing the attributes of a situation separately might already be sufficient to share understanding, and analogies are particularly useful in indirectly referring to collections of attributes, without uniquely defining the situation at hand. If a generic pattern appears is sufficiently common, then perhaps it will get a name, but is often only implied.
Hi Joseph, thanks for your reply, and the link to your SESYNC pursuit. I would be interested to see any published points of views or discussions on the matter of generic (your denomination or the reult of the SESNC pursuit?) versus problem solution pattern, and on splitters and lumpers.
I forgot to mention (which I did in the other post on analogy) that I am pursuing a PhD on the topic, with the objective of enhacing ‘pattern literacy’ both for decoding (understanding/interpreting) and encoding (designing/orienting) systems. One of the key objectives of my research is the operationalization of patterns in tools and methods that can be combined in various intervention methodologies (as a semi structured way to observe and model, facilitation inferrence and the cognition-to-action cycle).
I’m not sure yet whether I will limit myself to what you call ‘generic patterns’ vs ‘problem solution’ design patterns. It is likely I will keep both and express a design pattern as a combination of ‘generic patterns’, i.e. units of meaning making in my hypothesis. So having said that, I do think what you call generic patterns can be operationalized, and I am wondering for example whether they could not be used for adaptive modeling of complexity such as described in Pete Loucks post: Model complexity – What is the right amount? (https://i2insights.org/2016/11/03/model-complexity/). As units of meaning making, they could also be seen as units of adaptive modeling, enabling the construction and complexification of a model as we go. You seem to consider that generic patterns ‘come in catalogues’. I think they can also be nested and interrelated in pattern languages just as Alexandrian patterns. How to do that best is what I will be researching. Has there been any work in the SESYNC project about using patterns or pattern languages of any of the two kinds for modeling?
As far as splitters and lumpers are concerned (I like the metaphor), I think that patterns always come at various levels of granularity or abstraction. The systems sciences community has been on a quest for ‘general systems principles’ which could be labelled ‘general systems patterns’ too, trying to collect ‘isomorphic patterns’ or isomorphisms to draw general principles/patterns from. This is an endless endeavor. Systems philosopher David Rousseau writes that “knowing more isomorphisms only increases confidence in the existence of principles without making them easier to find”… A direction I am working on is rather than seeking universals, to find ways to semantically connect isomorphic patterns and work on graphs and proximal distance, where splitting and lumping can be done visually.
Thanks for continuing the conversation.
– We’re working on a paper from the SESYNC pursuit, but don’t have anything ready to share yet.
– The distinction between patterns in a generic vs design sense was something we had to tackle in deciding the scope of our work. I agree with the view of generic patterns captured in Scott Peckham’s post (https://i2insights.org/2017/05/23/explaining-patterns/)
– Lumpers vs splitters is a long standing issue (https://en.wikipedia.org/wiki/Lumpers_and_splitters). We just noticed that it was affecting our work too.
– I think your PhD topic is very worthwhile and look forward to reading more about it. My preference for operationalising design rather than generic patterns is a personal one, and I would be quite happy to be proven wrong.
– I recently came across a paper that seems to agree with the relationship between design and generic patterns we have been discussing (and connects nicely with Christian Schunn’s comments):
Kohls, Christian, and Katharina Scheiter. 2008. “The Relation between Design Patterns and Schema Theory.” In Proceedings of the 15th Conference on Pattern Languages of Programs – PLoP ’08, 1. New York, New York, USA: ACM Press. doi:10.1145/1753196.1753214
– I wouldn’t say that generic patterns come in catalogs. Rather, design patterns are often presented as catalogues. I would say generic patterns are sufficiently generic that they don’t come in any particular form at all, and could come in any.
Within our SESYNC pursuit, we’ve been experimenting with documenting modelling practices using one page per concept (in a wiki), concentrating on pages for solutions (as design patterns), but also including pages for recognised problems (that then link to possible solutions). When pages are fully developed, they end up looking like a pattern language, with one design pattern linking to others. In the early stages of a page, it’s mostly a list of ideas and links to other pages, more like a catalogue.
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?
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?
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.”.