Thought-provoking article on "Seven Forms of BPM"
- November 11, 2008
- 0 Comments
I’m not sure there are exactly seven forms of BPM, but Tom Baeyens writes a thoughtful article here that lays out 7 use cases and how they are addressed by JBoss jBPM.
Before we even get to the 7 forms, Tom has an insight that is key to understanding why BPM systems are a bit “different”:
A key capability of BPM systems is that processes steps can be wait
states. For example in the business trip process above, nodes ‘manager
evaluation’ and ‘ticket purchase’ are human tasks. When the execution
of the process arrives in those nodes, the system executing the process
should wait till the assigned user completes the task.
From a software technical point of view that capability is a big deal. As the
alternative is a bunch of methods that are linked by HTTP requests,
Message Driven Beans (MDB), database triggers, task forms, etc. Even
when using the most applicable architectural components available in
Java today, it is still very easy to end up in a bunch of
unmaintainable hooks and eyes. Using an overall business process makes
it a lot easier to see and maintain the overall execution flow, even
from a software technical perspective.
I couldn’t agree more with this, though it is a sort of “under the hood” consideration. It is part of why well-designed BPMS packages can scale really well with respect to the number of process instances that might be in a resting state (waiting for something to happen). Any BPMS solution that is holding all these instances in memory is going to be at a distinct disadvantage because for most of the time a process instance is alive, it is in a waiting state, waiting for an activity to execute, for a human to act, etc. and not actively processing work.
Setting aside scale, its just hard work to write the code that surrounds such wait-states correctly and you don’t want to have to write this code every time you confront such a problem – rather, you want to use a BPMS that seamlessly represents these wait-states in a diagram, giving the developer the ability to focus on the functionality of the process steps or the flow of the process, and not get caught up on the internals.
A couple additional thoughts on the seven forms (use cases) he outlines…
For Use Case 5, Visual Programming, he lists a few benefits:
With visual programming, we will target developers that do not yet have
the full skillset to develop in Java. They can graphically specify the
activities and draw transitions to indicate the control flow. Instead
of typing Java code, just put blocks like ‘perform hql query’,
‘generate pdf’, ‘send email’, ‘read file’, ‘parse xml’, ‘send msg to
esb’. Instead of writing Java, they will be composing software programs
by linking activity boxes in the diagram and filling in the
While simplifying activities like stringing together queries and PDF generation without writing that code may make this operation more accessible to developers without these Java skills, I would contend a different benefit: Things that should be easy (or rote) become easy (or rote) and therefore free the mind to focus on the bigger business problem. This is akin to the value I receive from a BPM system hiding the details of implementation of parallelism from me. While I may have the skills to write this code, it is tedious to write, and expensive to get it right. So you don’t want to roll this kind of code in a one-off fashion – you want to write it once and re-use it liberally to get benefits of scale. To the extent that a visual environment frees the developer to focus on the important abstractions of the process, it is a big win. (Note: As soon as I read Use Case 6 it precisely points out my thoughts about threaded programming, by pointing out that you can use a BPM system as a thread control language).
What really intrigues me is whether Tom and the JBoss jBPM team can create the necessary interfaces and utilities around jBPM to allow the creation of the Domain Specific Languages that can be implemented in jBPM (e.g. BPMN). While Tom apparently doesn’t see much value in the use of BPMN for executable models, my experience differs (and, since his technical approach doesn’t preclude BPMN for executable models in the future, the disagreement is more theoretical). Perhaps we can change Tom’s mind about this! While I think it is possible (and even useful) to create BPMN models that are not intended for execution, I believe a good technical implementation can still be accomplished with BPMN (plus technical details captured in context of the process). And this technical implementation can still be understood by the Business.
I think the problem isn’t BPMN… its a lack of imagination about how to capture business and technical details in different layers so that the user of these authoring tools can show or hide the “layers” that are interesting to them. For clarity, I think “technical layer” could include adding additional BPMN elements to the diagram, not just scripting and code and variable input/output details. And I think tailoring the visibility of details in the diagram is a key component in making a single model multi-purpose in audience.
I’ll definitely have to keep my eye out for jBPM 4…