Design Patterns in BPM – Lost Cause?

Scott Francis
Next Post
Previous Post
Sandy Kemsley covered Janette Wong’s talk at CASCON recently. The point of the talk was to discuss applying workflow patterns to modeling business requirements, and turning those into executable business processes. A good bit of the commentary revolved around all the hard work still required to make a design pattern actually executable – in particular with respect to role-based task assignment:
She used an example of an “authorization” business requirement, where manager can create confidential requests, and transfer those confidential requests to others. This can be matched to the standard role-based distribution pattern, which is fine for modeling, but then needs to be mapped to an implementation platform: in this case, some combination of WebSphere Process Server (WPS), LDAP or other directory service for user authentication and authorization, a workflow client application for human task management, and any other data sources that include user/role information. This multi-system implementation requires not only a conceptual mapping of the process and roles, but also actual integration between the systems that house the information. WPS provides instance-based authorization roles, then needs to bind that to the other sources at runtime in order to populate those roles; it doesn’t automate the solution, and in fact only provides a small amount of assistance in getting to that mapping. This is complicated further by role and authorization information that is spread out over multiple systems, particularly existing legacy systems; the business may think of the roles as being encapsulated in one of these other systems, which then needs to be mapped into the executing process.
I feel like the patterns (like “multiple instances without a priori runtime knowledge pattern”) are more accurately described as key phrases or constructs, rather than patterns (though there are exceptions to that generalization).   Wait, what is the problem the “multiple instances without a priori runtime knowledge” solves?? I think more of something along these lines in wikipedia.  And the kind of patterns you are likely to read on Anatoly’s blog.  In wikipedia, an “observer” pattern tells me a lot about what it might be doing.  Anatoly’s “Do Redo” pattern rings true, for example.  They describe what they attempt to solve (for the most part). Of course, many people misunderstand the point of patterns. They wonder why there is still so much work to do!   But patterns are not libraries of code – they’re patterns of design and code.  Its like knowing how to tie a square knot.  Although you know the pattern, you still have to tie the knot each time you want to use it.  Design patterns are much the same way. The point of the design pattern isn’t that it is less work – it is that you already know you have a good solution if the design pattern fits your problem definition.  The problem with the workflow pattern site is that it lists solutions with no problem. Anatoly’s blog actually covers design patterns quite well:
Pattern in BPM is a typical process fragment of typical way of communication between processes (some examples). One may ask: which one is more usefull? My opinion it’s a pattern:
  • Templates are specific (one process – one template), patterns are universal. A good pattern can be used in a variety of business processes regardless of the industry.
  • A practical benefit of using a template may be less than expected. It usually covers the happy path only and the devil is in details – various workarounds, escalations and exceptions.
  • The effect of using the right pattern can be large. For example, there was a case in our practice when the process plotted at 6 A4 sheets glued side-by-side was reduced to the elegant design with just 15 activities by using the right pattern.
  • The value of the antipattern is its ability to preserve you from mistakes. The price of a mistake is unlimited in theory and sometimes it’s really big in practice.
And yet industry analysts continue to overly focus on templates… I’d rather have design patterns and useful, re-usable components.  To my mind, templates try to “automate” the process design effort – to commoditize what cannot easily be commoditized.  Design patterns “enable” the process design effort – empowering and improving the design effort (as do re-usable components). Design patterns in BPM aren’t a lost cause- they’re a key enabler of the successful process designer.  But names matter- and in that department, Anatoly’s approach is vastly superior.
  • Pingback: Tweets that mention Process for the Enterprise » Blog Archive » Design Patterns in BPM – Lost Cause? -- Topsy.com()

  • Flanders

    How much flexibility is needed to be successful? I don’t think I’ve ever seen a template that also accounts for intelligent modification and the human element in the design process.
    –Pat Flanders (www.activevos.com)

    • How much flexibility for templates? or for patterns?
      They are two different things…

      Templates – usually once you start modifying a template, you can never go back – ie, you have permanently branched your code.

      Design Pattern – don’t think of this as code or implementation – it is concept – and helps organize the human element in the design process…

      • You see templates as CODE. That is the main problem with BPM. If however the template is modifyable by design, then the original always remains there and new template variants can be created by users without problem and reused.

      • You make a fair point that they don’t have to look like CODE to the business user. (but let’s be honest, for most BPM tooling, they do look like code. In fact, to most people “rules” look like code. I’ll concede the point on papyrus itself)

        But, the main reason I refer to code (outside of the comment above) is that templates are concrete implementation (and therefore, there is code behind them, whether that code is written by a software vendor or an IT person), whereas in the case of a design pattern, there literally isn’t any code required to understand what the pattern is and when to apply it.

  • Scott,
    I just posted my opinion on eBizQ, but I wanted to share it directly here too, here it is:

    I’ve been working both on software engineering (where design patterns have basically redefined the entire discipline) and in web and BP design.

    I think to pattern as reusable design solutions to known problems. The concept is a very abstract one.. actually, as you may know they have been first used in architecture (meaning bricks and concrete, not software :-) See: http://en.wikipedia.org/wiki/Christopher_Alexander ).

    I agree with you on the purposes of patterns and on the fact that they don’t really induce a fixed implementation
    [As a side note: the Hashmap example, while it gives a good idea of the point, is already too detailed to be called a sw pattern, that’s already a design solution.]
    However, while in software engineering I see patterns as usable in every setting, I think that in BPM they can be useful for composition of rather standard processes only. This is not so bad, since I would say that a large percentage of processes may fall in this category. Anyway, for sure ACM is not a field where a see an easy application of patterns, since ACM addresses a set of problems that are inherently not codifiable a priori.

    In the academia van der Aalst and others have codified a fairly complete set of workflow patterns (http://www.workflowpatterns.com/), which are a useful tool for some purposes (e.g., comparing the expressive power of different workflow languages), but I’m not sure they are nearly as useful for actual BP design within industrial scenarios (honestly, I haven’t seen anybody using them in this way; have you?).
    Also, I recently discovered a set of more practical patterns here: http://improving-bpm-systems.blogspot.com/2010/11/ebizqnet-what-key-methods-do-you-use.html .

    As a concluding remark, I’m not really sure about what is the real difference between a pattern and a template. Here is my (possibly simplistic) interpretation (opinions and criticisms are welcome): a pattern is a simple solution to a small problem, that composed together with others can contribute to a solution of a complex problem; a template is a complete solution which is completely configurable for being adapted to different context and therefore address similar situations.

    • Marco – thoughtful response! And you’re right, patterns redefined software engineering as a discipline (and not just software industry).

      Regarding my HashMap example – I won’t argue with you :) Sometimes finding a good example is hard! HashMap is not a pattern, it is an implementation (you could think of it as a template in some respects). The pattern would be something more like “fast retrieval of objects from a collection”–> HashMap. Well, its an attempt to explain, at any rate…

      I think even in highly custom processes, there are sections of those processes that could be described by Patterns. Not the whole process, typically. And it may not be about the “process flow” per se, but about task routing or prioritization, etc. There are several areas where patterns and anti-patterns can be useful to the process-designer.

      Agreed with your assessment on the van er Aalst patterns. Useful for tool evaluation (up to a point). Not useful to BP design/designer.

      Difference between pattern and template – the simplest explanation I can give is this:

      A Pattern is a generally useful solution design (not implementation) to a known problem (e.g. the Factory pattern or the Observer pattern… or in building – the steep roof for cold-weather climates).

      A Template is a complete or partial implementation of a solution to a problem (e.g. the abstract class in Java, or something implemented with callbacks that you are intended to fill in… or in building… a partially built roof that you will adapt to your specific building, but once adapted it becomes unique implementation for that one building. If I’m in Florida, I have no need of your steep roof template).

      Templates are not, by definition, completely configurable or adaptable – how configurable and adaptable depends on who wrote the template ;)

      Also, at first glance I like this list you pointed to: http://improving-bpm-systems.blogspot.com/search/label/practical%20process%20patterns

      I’ll have to read it in more detail before writing about it. Thanks for the reference –

      Scott

  • Francis, great observations on patterns versus templates. Also Marco’s opinion can be discounted but it builds on a number of assumptions. I especially agree that a pattern is more generic than a template. But then a template does not have to be a complete end-to-end process. A design pattern also just covers the abstract flow and then one has to spend a lot of time on making it work by adding all the data, resources, content, rules and more.

    I propose that the business people themselves must be able to assemble templates of all these elements and if they are goal-oriented then they become easily reusable without additional work and if they don’t fit perfectly then they can be adapted at runtime. Yes, design patterns are for the engineers but templates are for the business people.

    That’s the reason that there is this focus on them. As long as BPMS require design patterns they aren’t made for business people and that will be the reason to move on to something else.

    • 1. agreed template doesn’t have to be end-to-end (neither does a pattern).
      2. absolutely correct- a “pattern” is a conceptual design, that we know from experience is a good solution to certain circumstances. Still have to do all the data, resources, content, etc.
      3. For your assertion that business people must be able to assemble the templates – this requires that the templates (in combination) adequately express the business. (maybe that’s obvious – but many of the “templates” I’ve seen in this business don’t actually solve the problem – and customizing them requires a lot of technical work – rather than business modeling.

      Finally, I have to disagree with the idea that the business can’t use design patterns in general (although, I’ll admit, for much of the work that goes into a typical BPMS, your statement would be accurate). They use these design patterns all the time in their execution of their jobs.

      Check out http://www.bp-3.com/blogs/2010/11/furthering-the-startup-process/ for a description of how one can use design patterns to identify and test business models (in a startup).

      Design patterns are a powerful concept that can help anyone do their job better – pattern recognition, followed by execution of the best-fit pattern… (But I admit, usually when people refer to design patterns they are talking about technical subjects of some sort).

    • Anonymous

      Max, I agree that a template does not need to be an end-to-end process (in terms of breadth). With complete solution I meant something covering all the aspects of the solution (in terms of depth, i.e., including all the issues from data to process to roles and so on).

  • Pingback: Tweets that mention Process for the Enterprise » Blog Archive » Design Patterns in BPM – Lost Cause? -- Topsy.com()

  • Im not a lover of design patterns as such for BPM, but thats because I dont like the concept of a designed map. I think design patterns are for developers and technical people. The issue with BPM is that it is supposed to be for the business, so BPM delivers designer tools for us to use to build a map…To build a map we use our design patterns but we leave it up to more business facing people (well supposed to).

    I see that templates are mentioned in the discussion thread and I have to say, for a business person, a template is far easier and as such I think delivers more to a business. But a template need not cover the complete process, it need not be rigid and can be open to adaption. In such a case, are we not using design patters to create our templates???

    I dont see BPM growing much more within the business world until it is more adaptive. To do that, BPM needs to move away from flowcharts and reliance design patterns to deliver them…

    • Of course you can use design patterns to create your templates – and hopefully you do! And you can use design patterns to write the software behind the templates.

      Business folks generally like templates better. But they usually don’t understand the degree of lock-in they acquire when they go with a template. SAP’s industry templates come to mind. Those were flexible, right? :) And we have done several projects for customers who own two BPMS… one that had templates, and one that didn’t rely on them. The first BPMS tool solved a couple problems pretty well and the templates seemed somewhat helpful for that. But when the customer wanted to address other, more general problems, that tooling fell on its face with complexity. The templates had lots of clever “hardcoding” by smart people from the software vendor, that wasn’t easily replicated in another domain.

      The second BPMS was brought in to address these other areas (which, it turns out, there were a lot of), as the more general process platform…

      So when someone says template, and flexible, in the same sentence, my skepticism increases dramatically. It isn’t impossible, but history isn’t on their side…

      Far from moving away from design patterns, BPM needs to leverage them further to improve on delivery. To the extent that there are design patterns to support more adaptive behaviors by the business, those should be adopted.

      • I think the more we move to design patterns and designer tools, rigid process flowcharts etc the more we move away from what the business actually requires and understands …

        I think the problem with the term “template” is what has gone before. Templates are much better for business to utilise and understand, and they can be put together by us techies using our design patterns…But I am talking not about “flexible” templates, rather templates that can adapt, change and be changed based on the actual requirement of the end user (not a BA or author etc). I see a template like this as a very “loose” and “fluid” thing, with its first implementation being a best understanding of a process at the time. I am sure that after a couple of months of it being live it will look very different to the origonal…

      • You can look to something like Blueworks (www.blueworkslive.com) for an example of an implemented template process. They’re pretty simple templates, mind you. Even when the “author” finishes, they’re still simple templates, that can be customized at runtime by the users. But this isn’t a full BPM solution, these are for the looooong tail of processes that currently get done via email (with no tracing, no audit trail, no accountability).

        It will be interesting to see how the middle can be addressed.

  • LoreeRaine2

    Fantastic ideas , I was fascinated by the info ! Does anyone know where my assistant might obtain a template USSS SSF 1604 document to complete ?

  • pilar coats

    Hi, my assistant completed a template USSS SSF 1604 document with this link https://goo.gl/WBJiuR.