Following my recent post on BPM 2.0, Sandy Kemsley, one of the few independent analysts covering the BPM space, was quick to agree with our updated definition of BPM 2.0, at the exception of one point (out of sixteen): support for BPEL. The question of BPEL vs. XPDL, (or BPEL vs. nothing) has been one of the most debated topics in the decade-long history of BPM. Here is why BPEL matters.

First, let me make something clear, once and for all: nobody should ever try to write BPEL code by hand, unless they really have to. As far as I’m concerned, the ones that really have to are employed by BPM vendors whose products support BPEL. BPEL is an extremely powerful yet very complex language, and I don’t think there are more than a few hundred people around the world who can write decent BPEL code by hand. BPEL is a precise yet verbose language that was conceived to be produced automatically by code generators, not written by hand. In other words, BPEL is for computers, not human beings, at least not the ones I usually hang out with.

Second, should you really want to write code by hand, you should use a simplified version of BPEL, based on a less verbose syntax, and such a language is currently being developed by Intalio as part of the Apache ODE project. It’s called SimPEL, and it’s something that Ruby or Ruby on Rails folks will love.

Third, should you not want to write any code, you should move a step up the stack, and produce your BPEL code with a BPMN designer rather than a visual BPEL editor. The reason for it is pretty simple: BPEL is a complex language because of its semantics, not just because of its verbose syntax (which makes it complicated, but not necessarily complex), and a visual BPEL editor does very little to alleviate this complexity.

Now that we all agree that we should stay as far away from BPEL as possible, why on Earth does it matter that the core process engine runs BPEL code vs. XPDL, Java, or any proprietary process execution language devised by some BPM vendor? There are very many reasons for it, so let’s go through them one by one.

BPEL won the war of standards
Whether you like it or not, BPEL won the war of standards. While we (Intalio) lost a battle when BPML was supplanted by BPEL (because we had failed to secure IBM’s support for it), the war was eventually won when BPEL 2.0 was released (with Intalio’s support), and all major vendors adopted it against XPDL, including Microsoft, Oracle, and SAP. Some legacy workflow vendors might find delight in trying to re-play lost battles of the past (like some nostalgic French patriot dreaming of what could have been had Bonaparte’s army won the Battle of Waterloo — I know, I’m French), it’s time to move on. Really.

BPMN is not enough
Many people who fought for XPDL five years ago are now promoting the idea that neither BPEL nor XPDL really matters, and that all we need is BPMN. After all, BPM is for business analysts (wrong), and all they care about is what the process looks like. This argument is disingenuous at best. Executable processes cannot be designed with BPMN alone. A BPMN diagram is the process’ skeleton. For the process to walk (or run), it needs flesh around its skeleton. BPEL is the DNA that is used to produce it. Pick the wrong underlying language, and you end up with the wrong DNA. What’s missing in BPMN for it to describe executable processes? Data. Why is data important? Because a process without data is like a living being without language: it might walk or run, but it can’t speak nor listen. If your BPM vendor of choice is advocating that only BPMN matters, they’re using proprietary ways to make your processes fully executable, usually requiring a lot of custom code development, and this is the last thing you want for your processes. Whenever you find yourself listening to such a misleading marketing pitch, simply ask the following question: “Can you show me the code behind the boxes and arrows?”

BPEL is built upon the right mathematical model
A BPM vendor has three options to make processes executable: BPEL, XPDL, or their own language. If they use BPEL, they’re leveraging the Pi-Calculus mathematical model for supporting the execution of distributed and collaborative processes, taking advantage of one of its very powerful features, channel passing. If they use XPDL, they do not benefit from such a capability. If they use their own language or execution model, they do not benefit from the academic work that is validating and strengthening existing standards.

BPEL supports distributed transactions
Thanks to the notion of Scope, BPEL 2.0 supports distributed transactions that can be executed through the battle-tested two-phase commit protocol. Neither XPDL nor any proprietary process execution model I know of supports it, which makes them unsuitable for a broad range of enterprise applications. Again, you could hard-code distributed transactions within software components like Enterprise Java Beans, but this is not BPM (at least not BPM 2.0), it’s old-school OLTP.

BPEL is the standard
BPEL won the war of standards, and as such became the industry standard, and standards matter. You might not care to know about them, but you definitely care to know that your system is built on them. If you own a car, you’re glad that it’s running on standard gasoline, and that you can get your refill at any gas pump, operated by any oil & gas company — even though you hate the fact that gas is so expensive nowadays. It’s the same for a BPMS. If it’s built on top of BPEL, you’ll be able to take the processes you designed with its tool, and run them on another vendor’s engine. You cannot do that with a BPMS built on top of a proprietary execution model. Saying that BPEL does not matter when selecting a BPMS is like saying that SQL does not matter when selecting an RDBMS. Who in their right mind would buy a database engine that does not support SQL today? Why should it be any different with BPM and BPEL? This totally escapes me.

Executable BPMN does not exist
Whenever challenged with the argument above, non-BPEL vendors make the point that BPMN is all you need, and that executable BPMN is coming soon. Supposedly, OMG’s BPMI.org is working on something like that, and if you read the Business Process Definition Metamodel (BPDM) with a strong-enough dose of wishful thinking, you might find it between the lines of this arcane specification that nobody supports. Reality is, there is nothing like executable BPMN, and should anyone develop such a thing and did a good job at it, they would end up re-inventing BPEL 2.0, or something very close to it. In other words, the combination of BPMN and BPEL is all you need to make processes executable. The two members of this duo play very nicely together, but separate one from the other, and the whole thing falls apart.