Does BPEL matter? (part 1)
I always thought that BPEL or Business Process Execution Language (an XML format) was created so that process definitions should be interchangeable between BPM vendors. The truth is that any product (BPM or not) locks a customer in, one way or the other. The most successful vendors in doing this are IBM, Oracle, Microsoft and SAP.
There are over 200 other BPM vendors in all imaginable flavors. Less than ten percent of those vendors support BPEL and their implementations are not fully compatible. Therefore it is strange that some claim that BPEL is the ‘de-facto’ industry standard. Yes, it is the only thing that comes close to something that looks like a standard. Of all the languages that anyone would want to code, BPEL is (like any XML format) not something you want to write natively. Certainly not a business analyst. But the vision and claim is that BPEL resembles process code that can be taken from one BPM vendor to the other with little to no effort. That, I am sorry to say, is an illusion.
When you look at how various BPM environments are implemented then you will find each one to be utterly unique. The possible combinations of operating systems, Java server versions, database servers, business rules, content integration, GUI frontend functionality, browser and portal functionality, backend application service interfaces (SOA or not) and more (such as security interfaces) go into the several thousand. BPEL exists in multiple versions (1.0, 1.1, 2.0 are quite incompatible) and allows proprietary extensions most of which are in native Java code. So it is an illusion that you can take the BPEL code along and then simply run it in another BPM environment.
Let me take this further. As you do not want to maintain BPEL code, why would you even worry about it? What you want to maintain is your processes and these should be maintained in a graphical manner and if at all be saved in something like BPMN, which is another dreadful XML format but at elast represent a graphical notation. BPEL and Java means that you need to work in Eclipse, which is a programming tool (another so called ‘standard’) and nothing else. BPEL is a functional subset of BPMN and thus a true roundtrip is not possible.
BPEL does not solve any other issues of BPM like the necessary process monitoring. A customer service centered organization does not care how you execute a process as long as it meets the business goals. So what we need is to monitor business data that represent those goals. Some of them may be process related such as elapsed time for completion of a customer service task. Monitoring business data requires access to those data and they need to be defined. In what way BPEL would support standards-based tools for business monitoring has not been explained.