In the early days of BPM – four or five years ago – everyone thought BPEL was the BPM standard, at least for runtime execution. Not long after, the importance of business-friendly process modeling came to the fore, and BPMN emerged as the standard for that. The mismatch between graph-oriented BPMN models, where you can route the flow just about anywhere, and block-oriented BPEL, where you can’t, didn’t seem to worry BPM vendors. After all, a model was just a model, a business requirements document in diagrammatic form. The BPEL designer would use the BPMN as business input to the implementation and go from there.
Then a new concept emerged, the BPM Suite, which included process modeling, executable implementation, and BAM in an integrated toolset that promised the improved business-IT alignment and agility needed to cope with ever-changing business requirements. Suddenly the process model became more than a business requirements spec. It was actually the first phase of the process implementation. No problem, said the BPEL vendors. We’ll just generate skeleton BPEL from the process model, and use that as the starting point for the BPEL designer. Voila! Business empowerment! Business-IT alignment!
But this notion of the interface between process modeling and implementation design as a one-way handoff was flawed from the start. One problem was on the modeling tool side. Exporting the model to block-oriented BPEL imposed new constraints on the diagram. A model perfectly valid according to the BPMN spec suddenly gave validation errors when you tried to generate and export BPEL. Another problem was on the BPEL side. Once the BPEL design was fleshed out, it inevitably began to diverge from the initial BPMN diagram, so business analysts lost touch with the implementation shortly after the handoff. So much for business empowerment!
We had what became known as the roundtripping problem. A process model created in BPMN or comparable flowcharting notation could not be easily kept in sync with the executable BPEL design throughout the implementation lifecycle. Essentially, you couldn’t update the process model from the BPEL. Once the toothpaste was out of the tube, you weren’t going to get it back in. So the model was not a continuous business view of the implementation. In fact, it was still what it had always been – initial business requirements.
The roundtripping issue took some of the BPEL-based vendors by surprise. Coming to BPM from the integration side, they found the idea of business people coming anywhere near implementation design distasteful to begin with. But as it became clear that business empowerment is a key piece of the BPM value proposition after all, they began to acknowledge that BPMN-BPEL roundtripping was, well, a real problem.
Meanwhile, a host of smaller companies began to demonstrate success both with BPM buyers and industry analysts by ignoring BPEL altogether. Vendors like Lombardi, Appian, and Savvion, focused on human-centric processes more than integration, led the way with a new style of BPMS in which executable design is layered directly on top of the process model, in the form of implementation properties of BPMN activities. The new style does not create a handoff between different tools (with different flow models, data models, and programming models), but leverages a single tool shared by business and IT, with business focused on the activity flow and IT focused on making those activities executable.
In this new style of BPMS, there was no longer a roundtripping problem. If IT needed to change the activity flow, the modified process model was immediately visible to the business analyst. The tooling itself encouraged business-IT collaboration throughout the implementation cycle, and fit well in agile iterative methodologies that significantly shortened the cycle time from model to deployed solution. The advantages of business empowerment and increased agility easily overcame the disadvantage of a proprietary BPMS runtime, and in recent years this style has become favored by a majority of BPMS vendors. When large standards-oriented middleware vendors like BEA and TIBCO jumped into the BPM arena by buying BPMS pureplays, they didn’t go for BPEL. Instead they went for the shared modeling/design approach, in spite of the proprietary runtimes, and both are gradually migrating their tools toward full support of the BPMN standard.
So one answer to the roundtripping problem is to say that it no longer exists, but was an artifact of an earlier day, trying to apply BPEL where it doesn’t belong… in BPM! I think that argument has more than a grain of truth to it. But it’s not the whole story.
For the past year, I have been training users, both business and IT, on process modeling with BPMN. Naturally, I tend to see students whose companies have standardized on BPMN for process modeling. But they are not coming because they have just bought Lombardi, Savvion, or Appian. In fact, more often than not, if they have already made their BPM runtime decision, it is BPEL. It’s a standard, a commodity, available open source. It’s what IBM and Oracle use in their BPM runtime. So there are compelling factors in BPEL’s favor. But standardizing on both BPMN and BPEL? No, of course it’s not logical. Usually those decisions were made independently by separate groups in the company, completely unaware of the other’s issues. But the decisions were made, and if BPM is going to move forward in those companies, we need to deal with it.
Having been in the roundtripping-is-dead camp for about a year, I now find myself having to confront this issue once again. In my BPMN training, for example, students want to know what strategies or patterns should they use in their BPMN diagrams that will fit well with their expected BPEL implementations. It’s not something I expected to think about when I started.
In the BPMN specification, there is an attempt to describe simple BPEL mappings for many diagram patterns, but it has been long recognized that certain patterns cannot be mapped in the ways described in the BPMN spec. BPMN tools that validate for BPEL export based on these simple mappings tend to give users a lot of validation errors if the BPMN is not drawn in strict block-oriented fashion.
Attempts to create more sophisticated mappings have been few and far between. The best I have seen comes from Marlon Dumas and collaborators at Queensland University of Australia and from Yi Gao, CTO of the startup tool vendor eClarus. They take different approaches, but agree on the general strategy, which is to identify the diagram fragments for which the BPEL mapping is straightforward, and transform or redraw the other fragments into semantically equivalent diagrams with straightforward mappings. Using this approach, the subset of BPMN diagrams that cannot be mapped to BPEL is actually quite small. In fact, a number of the problem patterns identified by Dumas are actually illegal in the BPMN spec. These techniques, however, have not been widely adopted to my knowledge by BPMN tool vendors. That’s issue number one.
Issue number two is more subtle, since the above-mentioned researchers start from the objective of creating “readable” BPEL from the BPMN, based on the assumption that process implementers still need to edit the generated BPEL. In my view, that’s totally wrong. The roundtripping problem may not be dead, but the model-design handoff paradigm sure is, at least for BPM. The collaborative implementation paradigm, in which executable design is layered on top of the BPMN model, is still the way to go. The way I look at it, BPEL is just like Java. You might generate it under the covers, but you don’t ever want to edit it directly. The part of BPEL worth leveraging is the fact that it is a standard and a commodity runtime, not a useful design language for BPM.
So if creating readable BPEL is not the right objective, what is? I think it should be defining the largest possible subset of BPMN that is automatically mappable (using the latest techniques) to BPEL, and then defining the mappings themselves. I need to know that, because I want to be able to teach my students the BPEL-friendly patterns to use in their BPMN diagrams. Already it’s a fact that BPMN training is mostly learning the diagram patterns that best express particular process semantics, so conceptually this is nothing new. Without direct BPEL editing, we don’t need to worry about mapping BPEL back to BPMN (but with direct BPEL editing, we certainly do).
With IBM, SAP, and Oracle expected to be influential in the BPMN 2.0 effort, we can expect to eventually see some help on this within the standard itself. But I don’t want to wait that long.
