Considerations on Patterns

In a recent LinkedIn thread initiated by @kentyer and in response to comments by @alshall I wrote the following, which I think is worthwhile preserving here:

Really, we need to go beyond the notion that Patterns “create structure.” That might be true in Alexander’s physical view of Architecture, from where this way of thinking originates.

In knowledge-work it is much more fitting to think about Pattern Transformation as moving from one Context to another . Then " Structure" emerges as the contention of “Forces” - remember, Forces are one of the key attributes of Pattern Forms - that operate in the generated Context .

This allows us to reason in terms of immaterial forces . Like people’s intentions and interests; and extend the Pattern Thinking to contemplate, for instance, Conflicts of Interests - by which we can then connect to Goldratt’s Thinking Processes and maybe find application of the Evaporating Cloud conflict resolution technique.

So I prefer to reason in terms of Contextual Forces rather than Structures . This allows us to capture immaterial and constraining forces, like our Mental Models .

Or maybe I should say Mental MOLDS.

And later:

The real power of Patterns is in the network that makes up the Pattern Language. This is what the “Design Pattern” approach in software development mostly missed out, but that was part and parcel of Alexander’s intent, from the very beginning. Most people understand “Pattern” as a single instance cookie cutter for a premade solution to some problem. That is as far away as you can get from Alexandrian Patterns.

It is the generative nature of successive Pattern applications / transformation that will bring about NEW solutions, via emergence. This the total opposite of cookie cutters. Patterns are NOT a catalog of premade solutions. Real world solutions are generated (some would say “designed”) by the application of a multitude of Patterns. And any single application can give rise to a new traversal path in the underlying network that is the Pattern Language; which in turn can lead to the discovery of new Patterns. A Pattern Language is a living and evolving body of representation of knowledge.


  1. structures / relationships

  2. forces

  3. solutions

… those are necessary but not sufficient. See the Pattern Development Process that I describe in my book, and the way you go from Analysis to Normalization to an actual Pattern Form.

One of the most important attributes is the recognition of the “Resulting Context” which becomes the gateway to further Patterns. Most people looking into Patterns don’t have clue about these elements, and how rich and deep Pattern Thinking actually is.

TameFlow is totally founded on Patterns. Real, Alexandrian Patterns - not the cookie cutter variants.

Any comments?

Are questions allowed? I missed asking questions :slight_smile:

Yes. Here is a comment. I think it is good to be able to describe a cookie cutter pattern in isolation. Then by applying a cookie cutter pattern many times to “similar type” problems a proto pattern may emerge. Then this could ultimately become an Alexandrian Pattern. Realizing then that an Alexandrian Pattern is not absolute truth but rather a solution to a problem given a context that with X% likeliness will result in something - a new context is where this begins to become interesting. When you mention mental models in relationship to patterns I find this fascinating because we could view our beliefs (belief system) as static - or maybe - a network of mental models that we do utilize subconsciously and that can also be applied consciously and deliberately with practice.

It might be useful to find cookie cutters, but it’s not constructive towards developing a Patterns perspective.

Patterns - even Proto-Patterns - do not exist in isolation. They are always put in relation to one another, through the transformation of contexts.

Patterns Thinking is a way to sense the wholeness, and yet be acutely aware of the details; acutely aware of the details, even when they might be blurry. (If that sound philosophical, it is.)

1 Like

Yes. So a crude example: If I have a cookie cutter recipe of e.g. how to prepare for and conduct an effective meeting by having:

  1. A clearly defined intended outcome of the meeting.
  2. An agenda (steps to reach the desired outcome)
    This can be fine and detailed - while having this in place is part of a much bigger systemic picture.

… and then? What happens next?

… and even before you begin: Have you defined the context? Have you defined the problem? Both need to be specific.

… and in the middle: your points (1) and (2) are not a solution. They are - maybe - two distinct solutions. Patterns must be crisp and clear. Bunching stuff together doesn’t work.

While I am fairly sure, that I understand your point, I am not sure how many have the stomach for the rigor it takes to over time observe patterns emerge - let alone viewing these as a pattern language.

There is naturally always a context. Let’s say that as an example there is a clearly defined business case describing some specific (measurable) outcomes. In order to achieve those outcomes - since there is a need to move and calculate a lot of data in a well defined process - then it is deemed meaningful to develop an IT system rather than doing this on paper or in a spreadsheet. At some point in time someone realizes that there are some requirements which have not been well enough described. Hence - call for a meeting. In the meeting invitation put a clearly defined intended outcome of the meeting (we could say this is the solution to a problem given the specific context).

Exactly! That’s why I am always weary when folks get happily carried away by wanting to find “patterns”… because I know they won’t do it!

Patterns are the theoretical foundation sustaining the TameFlow Approach.

They are not the operational support to get the TameFlow Approach ticking. We use the Mental Models to do that.

Therefore: unless you are prepared to treat Patterns as first order elements, and do all the homework, I strongly recommend to put them aside. You cannot engage with Patterns half-heartily. They demand serious commitment. I discourage you to even try, unless you are ready and prepared to go the full path. This is where the mastery aspect comes into play. It is a long, never-ending path. A way of thinking.

The book talks about “proto-patterns” for a reason: they are not Patterns in the full sense of the word. They are more on the “cookie-cutter” side than on the Pattern side… because people want recipes and cookie-cutters.