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.