Software engineers have been aware of patterns in knowledge management for some time, so why is so little known about it outside the community? EuroPLop chair Allan Kelly explains more about this useful technique.

For over 15 years, the software engineering community has been using a technique known as patterns to capture and communicate knowledge about software design and implementation. But despite much success in the community and over 40 conferences on the subject, this technique is little known outside of software development.

In early July, I was conference chair for the 30th annual European patterns conference, EuroPLoP. While a large number of the patterns presented for review originated in the software engineering field, many papers came from outside of engineering. Patterns on pedagogy, social change, business and management demonstrate the applicability of the pattern form and pattern thinking to the capture and communication of knowledge in many domains.

What are knowledge patterns?

The original ideas behind patterns come from the architect Christopher Alexander in his books A Timeless Way of Building (1979) and A Pattern Language (1977). But a small group of software engineers only started using the idea of patterns in the early 1990’s.

In 1995, Design Patterns was published, which introduced the wider software community to the ideas. Since then, dozens more pattern books have appeared but while the majority of these books concern IT issues, a few step outside the domain. For example, Fearless Change (Manns and Rising, 2005) contains patterns for introducing change into organisations.

Patterns are intended to capture a reoccurring solution to a reoccurring problem within a domain. The patterns themselves are literally a device which come in many forms but should always contain the key elements: context, problem, forces, solution, consequences and examples.

A pattern normally opens with a context statement that outlines when a pattern might be appropriate. A problem statement describes, as succinctly as possible, the issue under consideration. Problems need to be hard to be worth documenting and it is the forces section that describes in detail what makes the problem difficult to solve.

Hopefully, the reader is now in a state of suspense: how can this difficult problem be solved? The solution statement which follows provides the “ah ha!” moment when all is revealed. It goes on to describe in detail what needs to be done and how to do it, and this description then changes the pattern into a prescription for resolving the problem.

The consequences section follows the solution and describes the state of the world after the solution has been applied to the problem. It also outlines how the forces are resolved or mitigated. Finally, the pattern offers examples, or known uses, to show where the solution has been used before.

The poetry of patterns

While patterns need to contain all these elements, the actual form of the pattern is left to the author. Like poetry, there are many ways to write a pattern – some have section headings to draw attention to each element, others adopt a more narrative format which allows the text to be read like a story.

Sometimes a single pattern is all that is required to capture significant knowledge but, more often than not, there is a family of patterns – a pattern language. The names of the patterns in the language form a vocabulary that can be used to talk about problems and solutions.

At the basic level, the language provides vocabulary and a cookbook of possible solutions, some of which build on others and some of which are alternatives. Yet patterns are more than a cookbook. Alexander asks that each pattern should live and contribute quality to the world.

From a KM point of view, the pattern creation process is as interesting as patterns themselves. Authors are encouraged to submit their patterns to one of the regular PLoP conferences, for example. The objective of the conference is to improve a paper, so once a pattern paper is accepted to a conference, the author will be assigned a named shepherd. The shepherd will then spend several months (typically over email) advising the author on how to improve the paper prior to the conference.

At the conference itself, the revised paper will be reviewed by a group of pattern authors, who offer advice for improvement. Together, the pattern structure and review process not only improve the pattern by making it more readable but also tease out the tacit knowledge that is often lacking from simple problem-solution descriptions.

This brief description only begins to scratch the surface of how patterns and pattern writing can help with knowledge management, however. Hopefully, patterns won’t be confined to architecture and software engineering for much longer.