Janette Wong, a long-time IBMer who is now an independent consultant working as a solutions architect, discussed the use of workflow patterns in modeling business requirements and turning these into executable processes.
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.
She also discussed the requirement of a multi-item Inquiry, where multiple sub-inquiries will be created from the main inquiry (such as fraud investigations), and the exact number is not know at design time. This matches to the multiple instances without a priori runtime knowledge pattern, where you have multiple parallel sub-tasks that start and end independently, although the master activity has to wait for all children to complete before proceeding. This is similar to what we are seeing emerging in many case management implementations, where the parent activity is really the case itself, and the child tasks are those activities that the case workers initiates in order to move towards case resolution.
Wong observes that in spite of the length of time that BPM systems have been around, the larger patterns are not well supported by many of the systems although they are prevalent in real-world situations. She talked about the need for better design in process modeling tools, so that it is more obvious how to use the tools to implement these common, but complex, workflow patterns.
(thought i posted this already, apologies if it shows up twice)
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). I think more of something along these lines: http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
And the kind of patterns you are likely to read on Anatoly’s blog.
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 (for the most part).
The workflow patterns are higher level than standard software design patterns, although does fall into the more general definition of “pattern”. Remember that the workflow patterns were developed by academic researchers who were likely more focused on mathematical proof than executable software.
Really, the workflow patterns are more like the atomic units of process topology; the idea is that if your process modeler can handle all of the workflow patterns, it can be used to model (and hopefully execute) any process. Check the About page on the workflow patterns site for a better perspective on this academic initiative that turned into a BPMS evaluation technique.
Sandy –
I think you’re right, that coming from an academic/mathematical background the “patterns” tend to reflect that.
I think the patterns that process authors should learn are a bit higher level, and may be reduced to a collection of the patterns identified by the academic group, but as they are currently formulated, process authors aren’t likely to apply them to their design process. And it is applying patterns to the design/implementation process that is most interesting to me.
Regarding the proofs of what you can model… many of the workflow patterns can be implemented in tools with a combination of BPMN and “decoration” (read: code) that is fully supported in the tooling authoring environment. It isn’t perfect but I think it helps explain why vendors haven’t worried more about solving more of these patterns (Because, they can, so long as the implementors are willing to make a few compromises).
I agree that you’re not going to see a lot of these in use by process designers; it was a bit odd to hear a consultant claim to use them all the time in practice. That being said, maybe process designers could learn something by familiarizing themselves with these patterns, since they could help to analyze a process more succinctly.
Interesting and relevant discussion for me as TIBCO’s new BPM product, ActiveMatrix BPM, explicitly supports a number of workflow patterns (separation of duties, chaining and piling) and being the Product Marketing Manager, I need to communicate this. Scott is correct that most patterns can be implemented using a combination of BPMN and code. However, this code can be complicated and implementing it takes away from the agility that BPM delivers. And while I agree that most process designers do not talk about workflow patterns per se, I have spoken with number who have had to implement specific patterns using “BPMN and code” – they immediately recognized the “pattern” and the value of explicit implementation in the BPM.
Jeremy, I like what TIBCO has started to do with some of the workflow patterns, and I think that some of the more familiar ones could be productized as you have done. There are some pretty obscure ones, however, where it may be a purely academic exercise to include them.
Every process designer has their own “patterns” of some sort: I still see patterns that are identical to those that I’ve been using for 15 years, such as your separation of duties pattern that is familiar to anyone who has designed processes for financial data processing.