A Word on the Meaning of Patterns
- July 23, 2010
- 2 Comments
“In many areas, patterns are used to codify best practices. A pattern describes a solution for a problem. Originally, patterns were used in architecture to describe architectural design ideas. In software engineering, patterns are used to describe typical software design solutions, for example like client-server architecture.
In business process management, the so called workflow patterns by Prof. van der Aalst and friends exist. In their original description, they described the most important 20 workflow constructs like loops, decisions, and sequence flows. Later, Prof. van der Aalst and other research fellows extended the list of patterns and revised the initial description (see workflow pattern homepage). Still, the original 20 workflow patterns are valid and a useful tool to learn a modelling language such as BPMN.”
I’m just not excited about the van der Aalst “patterns” that are oft-quoted in BPM circles. The more accurate statement is that they are snippets of BPMN that demonstrate how various “constructs” work. They’re useful demonstrations of how BPMN can work, and how to use a particular tool to diagram specific constructs. And the work of van der Aalst and colleagues was very useful as well in identifying edge case diagrams that expose tricky aspects of the notation’s execution semantics. They are not, truly, patterns as I would think of them. Showing three activities executing in a sequence is hardly a “pattern” any more than three lines of code that execute in a row are a pattern. Splits and joins are just constructs of the notation. The patterns don’t identify the usefulness of the pattern or the “why you would want to do this” aspect. In that sense, they largely fall short of the bar for a pattern in my book. A typical name for a “pattern” in this study : “Multiple Instances without Synchronization”… huh? A name only a parent could love. What’s the business case for this that helps me understand how it relates to business process? There isn’t one. The point of these patterns, documented here, is to identify technical edge cases and compliance, not to create patterns that you will base your actual design work off of … and maybe that’s my main complaint.
The “four eyes” pattern is a pattern (where n-1 potential reviewers have to approve something before it moves on). There are lots of real patterns out there – and generally they’ll get names that make sense- an “observer” pattern, the “shadow process” pattern, etc. Having voiced my complaint, maybe I need to take some time to document a few BPMN2 style patterns to clarify. Anatoly Belychook has described a few on his blog, in the past (as well as anti-patterns).