One of the fundamental promises of BPMS was supposed to be improved business-IT alignment through model-driven implementation. We’re headed in the right direction but the tools and standards don’t completely support it yet. In preparation for the upcoming 2006 BPM Think Tank, a gathering of BPM poo-bahs contemplating the next round of process standards, I have a modest proposal.
Here’s how BPMS was supposed to work: After your BPM team hashes out the basic workings of the as-is and to-be processes using yellow stickies on the conference room wall, they are supposed to record that hard-won understanding not in a simple Visio flowchart but in a process modeling tool. That tool should be based on a standard diagramming notation and semantics, and allow optimization of process performance metrics through simulation analysis. The notation should be independent of implementation architecture (e.g. workflow vs service orchestration), intuitive to a “business user,” and “abstract” in the sense that executable design detail is optional. Yet even with all these restrictions, the model should be able to generate some kind of artifact – a skeleton design – that can be imported into the implementation design environment and which encapsulates the key features of the modeled process flow, resources, and performance metrics.
In that vision, the Business Process Modeling Notation (BPMN from OMG) is the process modeling notation standard and BPEL from OASIS is the executable process design standard, at least for those BPM suites based on service orchestration architecture. A number of BPMN tools now can also export to XPDL, the standard for executable designs based on workflow architecture. So far so good, in theory at least.
But the need to export a diagram drawn by “business users” to a valid (though not yet executable) BPEL program creates some obvious problems. The first one is that not every flow you can draw in BPMN can be exported to BPEL – at least unless you draw it the “right way.” I found that out the hard way after transcribing a client’s hand-drawn flowchart into a BPMN tool. Everything was great until I switched on BPEL validation, when whole blocks of process turned red with BPEL error messages. BPEL doesn’t like “interleaved” process segments, looping back to previous steps, and other common features of user-drawn flowcharts. Of course, you can get around all of these problems by redrawing the flow using structured loops, control variables, events and other things that programmers take for granted. But not only does this turn the business user into a programmer, it creates a diagram that may be no longer intuitive to anyone on the BPM team. In the end, the effort to get the BPMN to be “BPEL-valid” was too great and I just built the skeleton design directly in BPEL.
Now you might say that’s not a BPMN problem but a problem of my modeling tool. Also, since the BPEL language isn’t functionally complete – it omits really fundamental things like human tasks, subprocesses, and data transformation – each BPEL-based BPMS is going to add those features using its own design constructs. There’s no way the modeling vendor could get the export right for every BPEL tool. What should happen instead is the modeling tool should just save the BPMN and let the design environment generate the BPEL on import. That might also eliminate the need to torture the BPMN into unintuitive patterns just to get valid BPEL.
That would be logical, except that the creators of BPMN standardized just the diagram shapes and lines, not how the diagram could be saved as an XML document! So there’s no standard way to share models with implementation tools other than by exporting them to BPEL (or to XPDL). That hole was widely discussed at last year’s Think Tank, and OMG is now addressing it with its Business Process Definition Metamodel. Let’s hope this effort comes to fruition quickly.
But now we come to the second problem, the heart of my modest proposal. The issue is how to keep the model in sync with the evolving BPEL design. BPM is based on the notion of a cycle of continuous process improvement. Remember, modeling and analysis aren’t just the first step of the BPM project, but are repeated periodically to optimize performance and cope with shifting requirements. Actual performance metrics continually refine modeling assumptions and simulation parameters, and the flow itself can be tweaked easily, relying on the inherent agility of service orchestration. But all of that implies that the process as originally modeled – the BPMN diagram, annotated with performance metrics and simulation parameters – remains accurate after the BPEL designer has finished the implementation. The model and the executable design have to be mutually interchangeable. It can’t be a one-way trip.
So the next challenge is re-creating BPMN from BPEL. That doesn’t mean all the executable detail needs to be surfaced in the diagram – but it shouldn’t be lost, either. You should be able to go from BPEL to BPMN and back to BPEL without losing anything you started with! In a sense, BPMN becomes a business-oriented diagramming notation, supporting both simulation parameters and optional executable detail, which remains fully interchangeable with and functionally equivalent to executable BPEL. Changes to the process can be added in either environment.
I have a hunch that creating the BPMN diagram from BPEL should be easier than going the other way, and that implementing such a bidirectional interchange would probably provide valuable lessons for tool vendors on both the BPMN and BPEL sides.
