BPM & Rules bloggers have been debating and discussing BPEL. Phil Gilbert’s entry discussed why BPEL is not BPM, which reminds one of some type of ZEN koan, hence the double entendre in the title. (I particularly like the one in the link about the short staff).

In my opinion, BPEL is not BPM, which is obvious, yet BPM 2.0, cannot happen without BPEL for a number of reasons. First, the support features of BPEL, including arrays and transactions, enable ‘code-free’ methods. Let me explain. A lot of the old BPM guard (you know who you are), have lovely diagramming tools, yet when it comes time to do anything complicated, you immediately drop into a Java (or what ever) development. This puts change management out of the reach of the business/technical types and recreates the Business/IT divide. I think the old-guard is threatened by the prospect of moving their BPM tools away from their Java-centric focus. I have been finding more and more young, uber bright, high-bandwidth business/technical types on the front line of the business world. Not all of them have the time to become J2EE experts, a 2-3 year process. Products like Intalio or Oracle’s Collaxa will empower this new generation.

For me, there is a deeper entanglement between BPEL and BPM 2.0 and it involves Pi Calculus and the ambitions of the BPM movement.

About 20 years ago, there was an academic movement, known as formal methods, which has become high confidence software(HCS). The HSC movement is responsible for the precise development of the avionics of the Airbus A380. A hidden outcome of HCS has been the adoption of strongly-typed languages, especially Java. Another outcome of HCS has been Pi-Calculus. One of the visions of the BPM movements is to be able to exchange processes. Right now, the only theoretically sound way to exchange processes, in a long-lived transaction is with systems that utilize pi-calculus engines.

Here is the analogy: the difference between Java-Based BPM tools and BPEL BPM tools is like the difference between C and Java. C is a weakly typed language. Formal methods yielded type theory and thus Java. Java is arguably a better programming language. Formal methods yielded Pi-Calculus and thus BPEL.
Imagine this scenario. A business person wants his customers to provide, at their pleasure, some structured maintenance information for research. If they elect to provide this information, they will receive some benefit; say a discount on their next purchase of products from the company. Advocates of BPM 2.0 want that same business person to be able to create email, the process that supports it, and the discount. Right now I believe we are at least 3 years away from this reality, yet unless the BPM industry embraces the correct manner and methods, especially BPEL, this Business /IT divide will continue.

Returning to Phil’s discussion he states” can you imagine Lou Gerstner lining up everyone and saying “OK, we’re going to save IBM by using BPEL.” No, yet I’ll wager Carly Fiorina wished she had something like BPM 2.0 to integrate Compaq and HP’s SAP systems, which had no small part in bringing her down.