This is the fifth edition of our weekly BPM 2.0 post. Today, I will try to explain why BPEL matters. Out of the 250 BPM vendors one can find on Google, less than 10 support BPEL natively. The other 240 usually make a case that BPEL does not really matter, for no business analyst would use it directly. They’re both right and wrong.

They are right in the sense that indeed, no business analyst — or process analyst for that matter — should ever have to write a single line of BPEL code. Instead, they will use a process modeling tool that will generate the code for them. But they are also wrong, for the code that is generated that way really does matter, for three main reasons.

First, using a process runtime that natively supports BPEL ensures that processes that are deployed onto it could be deployed onto an other runtime as well. As far as I can tell, this is the best insurance policy any customer could get. Admittedly, the fact that BPEL has multiple versions (1.0, 1.1, 2.0) and supports the definition of proprietary extensions — much like SQL with SQL-87, SQL-92 and proprietary stored procedures — makes such portability harder than it should be. Nevertheless, it’s a lot easier than having to go from the propriatery language of Vendor Foo to the one of Vendor Bar.

Second, designing processes that are aimed at being deployed on a BPEL runtime allows developers to make some assumptions regarding the execution environment that will host them: web service interfaces will be there to interact with processes at any point in their execution, audit trail data will have a certain format — or at least be defined against a common semantic set, and the collection of process constructs that such processes are defined with is known in advance, without any ambiguity. This makes the development of standards-based tools for business activity monitoring and process analysis and simulation much easier within the BPM ecosystem.

Third, and whether workflow vendors like it or not — usually they don’t, BPEL has become the de-facto standard in the industry. Most BPM vendors today used to be workflow vendors in the past, and the workflow community at large did a pretty good job of fragmenting the market, by making sure that nobody would ever develop nor support any useful standard. Think of it as a divide and conquer strategy where nobody actually conquers anything more than what was there at the first place. As a result, workflow vendors have a vested interest in downplaying BPEL, in order to slow down its adoption and their own evolution toward irrelevance. But make no mistake. When all major IT vendors — including IBM, Microsoft, Oracle and SAP — agree on any given standard, not much room is left for others. QL might have been better than SQL twenty years ago, but IBM’s support for SQL made it a sure winner. Support for XPDL would be a noble pursuit — albeit quixotic — if only XPDL was technically superior to BPEL. It’s not, therefore I see no reason not to use BPEL. And if you happen to use a product that does not support BPEL natively, make sure to ask a BPEL vendor to help you migrate to one that does. Last time I checked, it was not all that difficult.

Last but not least, one of the best places to learn more about BPEL is on the blog of one of my top competitors, the excellent BPEL Radio published by Edwin Khodabakchian, Vice President of Product Development at Oracle. Edwin was the founder of Collaxa, the company that developed the first working implementation of BPEL. He knows what he is talking about, trust me on this.

Author’s note: Tom Debevoise wrote a great follow-up article. Not to be missed!