BPMI.org Redux

This article is an unedited version of this original article posted on IT|Redux.

A breakthrough, finally! After almost a month of back and forth discussions started by the now-infamous why BPEL matters post, and continued on InfoQ, the Workflow Patterns Google Group, and countless posts on this very blog, we finally reached a conclusion, drawn by Bruce Silver and relayed by David French. They are calling for the industry to develop a “Compliance Specification for BPMN” that would define the “elements, attributes, and flow patterns that must be supported to claim BPMN support.” What a great idea! Now, let’s take a look at how such a specification should be developed, and who could take the lead for such a project.

As of today, several things are missing to make BPMN a true standard in the industry. First, as Bruce Silver pointed out, BPMN’s semantics are “vague” and need to be clarified, especially with respect to the elements of the specification that should drive the generation of executable processes. Second, there is no standard interchange format for BPMN diagrams that would allow a diagram designed in one tool to be used in another. Third, if BPMN is to be used as overarching framework for describing executable processes, all “annotations” to the specifications that are required to turn a pretty picture into an executable process should be standardized as well, as well as the way to serialize (translation: translate into textual form) all these annotations.

To a certain extent, all this refers to the vision of “native BPMN engines” that has been promoted by some vendors lately. While the vision looks good on paper, what these vendors fail to realize (or advertise) is the fact that BPMN only deals with one dimension of processes: the flow of execution. But it totally overlooks another critical dimension of processes: data. How data flows through the process, how it is exchanged between processes, how it drives the execution of business rules throughout the process, etc. And guess what? Properly adding this data dimension to BPMN will lead to the complete re-invention of something that already exists: BPEL. So why not start from it, by using BPEL as default execution model for executable BPMN processes?

What Bruce and David call a “Compliance Specification for BPMN,” I would refer to as “Executable BPMN Specification.” It would unambiguously describe the elements, attributes, and flow patterns that must be translated into BPEL in order to support proper execution, and the ones that are there for documentation purposes only. With respect to the former, this specification should formally describe which BPEL code must be generated for which elements, attributes, and flow patterns, making the underlying BPMN to BPEL code generation fully deterministic and predictable. Such an effort should be supported by the proper formalisms, leveraging recent scientific papers such as the Formal semantics and analysis of control flow in WS-BPEL by Ouyang, Chun and Verbeek, Eric and van der Aalst, Wil M.P. and Breutel, Stephan and Dumas, Marlon and ter Hofstede, Arthur H.M. (2007).

In parallel to this effort, a group should work on a standard serialization format for BPMN. This format should be based on XML, canonically map the BPMN diagram’s graph structure, and be fully extensible so that vendors could add their proprietary decorations to it (font attributes, shape colors, icons, etc.). That’s the easy part. The difficult part is in understanding that we need two serialization formats, one for non-executable BPMN, and one for executable BPMN, the former being a subset of the later. A serialization format for non-executable BPMN can be developed right away, and should be a fairly straightforward exercise. All it would require is a thorough review of the current BPMN specification, and a fair amount of discussions among tool vendors in order to define the mechanisms by which the specification could be extended in order to support proprietary decorations. A serialization format for executable BPMN would not only require the completion of the first specification (for non-executable BPMN), but also the completion of the Executable BPMN Specification as well. Eventually, the three efforts should be combined into a single specification.

If this makes sense to you, please let me make some recommendations:

Properly define both ends of the equation
If your goal is to define a specification for executable BPMN, make sure to define what “executable” means, and there is no easier way to do that than by picking an execution language that already exists. As of today, BPEL is the most complete, most robust, and most widely supported, hence should be considered as the best candidate. Furthermore, this default execution language should be the only one you care about. The minute you start adding other options (like XPDL), the project goes off tracks, for you need to define an unnecessary abstraction layer. You go from meta to meta-meta, then from meta-meta to meta-meta-meta, and before you know it you pulled a German dictionary from your bookshelf in order to understand what über-meta means. Instead, just consider this exercise as solving an equation. For the equation to be solvable, you need to define both ends, BPMN on one side, BPEL on the other. Once you solved the equation, feel free to add variations to it, and see if the work you’ve done could be used with other target execution models (like XPDL). But make sure to solve the original equation first!

Do not worry about round-tripping between BPMN and BPEL
Round-tripping is a futile and wasteful exercise when attempted between two languages or notations that have a significant semantic gap between them, and so is the case for BPMN and any process execution language optimized for computers (like BPEL). The same is true between UML and Java by the way. Round-tripping should be set as a goal only between two languages or notations that are essentially representing the same thing, such as BPMN and its future serialization format for example. What this means is that there must exist a way to fully serialize BPMN diagrams on one hand, and a way to graphically display serialized BPMN on the other. And all this should work in a deterministic and predictable way, uniformly across tools.

Do not worry about the ugliness of the BPEL code
BPEL is to be produced by code generators and consumed by process virtual machines, not written nor read by human beings, so do not pay attention to the verbosity of the BPEL code resulting from the translation of executable BPMN. Of course, the BPEL code should be correct and as succinct as possible so that we can more easily apply formal validation techniques to it, but do not try to make it any simpler, for there is no point to it.

Improve BPEL whenever necessary
As many pundits indicated, some BPMN flow patterns cannot be translated to BPEL. In some cases, it’s because they should not, for the BPMN diagram is wrong — as in, it makes no sense at all. A smart BPMN modeling tool should detect such flawed patterns, and warn the business analyst that while beautiful, this flower-shaped graph is utterly meaningless. In other cases, the BPMN diagram is simply representing something that will not be executed by any kind of IT system, and no BPEL code should be produced. In yet other cases, the BPMN diagram can be translated into BPEL, but the resulting BPEL code will be ugly, and it would be preferable for the business analyst to change the BPMN diagram slightly in order to support cleaner BPEL code generation. A very smart BPMN modeling tool should detect such occurences, and make suggestions that could improve both the BPMN diagram and resulting BPEL code. Last but not least, in a few cases, the BPEL language might not be powerful enough to represent some BPMN constructs. I have yet to come across such instances, but let’s assume that they could arise, just for the sake of the exercise. If such were to be the case, take note of the limitation, and send it to the authors of the BPEL specification. If they do a good job, they might address the limitation you found in a subsequent version of the specification — BPEL 3.0, anyone? In the meantime, the non-executable pattern you stumbled upon should be added to the non-executable BPMN section of the specification, and marked as “not yet” executable.

If you follow these guidelines, you might get something out of the exercise.

Now, how do we get there? Well, if I’m the only one thinking that such an exercise would benefit the industry, there is not much point continuing the discussion, and all we need is for Intalio to better document the way we translate BPMN into BPEL. We already have a serialization format for BPMN (we donated it to the Eclipse Foundation), and we already generate valid BPEL 2.0 code for pretty much any BPMN diagram that makes sense.

But if there are other people out there who think that vendors and customers would both benefit from such a set of standards, we better start working on them now, and this begs the following question: where such a piece of work should be conducted? Which standards organization should host it? Should we propose it to an existing one, or should we create an ad hoc organization from scratch, and run with it?

Well, I have a fair bit of experience in this area, having founded the Business Process Management Initiative (BPMI.org) back in 2000, and chaired it for about four years. I have helped orchestrate its integration within the Object Management Group (OMG), and remotely followed their work for the past few years. I have also witnessed the evolutions of the Workflow Management Coalition, the W3C, and OASIS, and learned a few things along the way. From all this, I can safely say that the proposed exercise will fail if it is not conducted within a new group, which sole objective is to make it succeed.

I will leave to others the task of discussing why the aforementioned organizations are not suitable candidates for hosting such a project, and will just explain where the challenge lies: in trying to build this executable BPMN model, one has to bridge the gap between two specifications that are owned by two different groups: BPMN owned by the OMG, and BPEL owned by OASIS. Furthermore, this work has to be done in isolation from other specifications which integration would lead to failure, first among them XPDL owned by the WfMC. To make it perfectly clear, I have nothing against any of these fine groups of people, or the specifications they produced. I have strong opinions about their usefulness, but these should be for me to keep. The only thing I care about is the success of the project, for it will take significant resources to complete, and these resources do not come cheap, especially today.

So here is what I am proposing. If you’re interested by the notion of executable BPMN and believe that the easiest and fastest way to get there is to build it on top of BPEL first, then I invite you to join us (Intalio and a few others) in the creation of a new group tentatively called BPMLab. It will be a non-profit organization managed like the BPMI.org of the early days, which mission will be to develop standards for BPM. Membership will be open to anyone, will be affordable, and will get you in touch with people who share the same passion about BPM as you do. But make no mistake, BPMLab won’t be an advocacy group for BPM, or even less a place to learn about Business Process Re-engineering. There are plenty such groups out there, and there is very little we could add to their work. Instead, BPMLab will be a group of experts who can make meaninful contributions to the field of executable BPMN, in a constructive and pragmatic way.

BPMLab, anyone?