BPEL or Business Process Execution Language (an XML format) was created according to the vision that process definitions should be interchangeable between BPM vendors. While that sounds like a noble target, I question its validity. Today BPEL is only supported by that vision as in reality it is unfulfilled. I will explain why that is my point of view and why it causes opposition. People either subscribe to that vision or they are implied to have deeper, immoral motives such as locking customers in. 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. So maybe BPEL is not a visionary concept but just an ambition for more market share. The current expectation is that once these monopolists will fully endorse BPEL they will push the poor rest out of the market. The means could be a standards-based process language called BPEL.

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. Where it is part of a sales pitch it is a straight lie. It is true that you can upload the BPEL code, but that brings hardly a benefit.

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.

BPM as a principal concept represents also a vision where the noble target replaces pragmatic and realistic achievements. There are no vendor independent studies that prove that rigidly managed process flows are beneficial to a business. Executives chase the illusion that they can implement a business model with IT that will allow them to run the business by remote control.

For decision making and monitoring the business achievements against goals, it is necessary to have access to real-time business data. BPM people speak of using ‘a common semantic set’ when they mean metadata definitions that correlate to the service interface data. Therefore not only BPEL has to be compatible but also business architecture metadata. BPEL offers nothing for both needs at all. Presenting real-time business data to the business user in the process requires Java code to pull the data from the service interface and present them.

The other element that is needed for pragmatic use of process is business rules. One can convert business rules into BPEL, but then they cannot be executed as complex rule sets that are triggered by data changes or business events.  Business rules also act on business data so you need to code more Java to pull them from the service interface and pass them to the rule engine. Business rules have however multiple purposes with the most important one being so called boundary rules that are essential for auditing. The better your boundary rule set is, the better you will catch exceptions and violations automatically. Thus those rules should not really be an integral part of your process but rather an independent definition but tightly integrated into the process execution. There are some non-BPEL product that handle real-time data and rules quite well.

Some vendors propose BPM 2.0 and other visionaries already propose BPM 3.0. They say that it will not happen without BPEL. I think they are right. Therefore there will be no BPM 2.0. Or even 3.0. BPM in its current rigid form with or without BPEL and BPMN is a dead-end. New technology concepts are required.

What would this new technology need to look like? If any technology concept can foster successful process management, it has to be business facing and enable real-time metadata-driven model execution, while engaging business directly in continuous process change cycles. To enable business participation, a secure change management environment is required that controls the lifecycle and manages deployment.

The only way that business users can be involved in designing processes is by using graphical means of process representation that has to include rules and event handling. Non-technical business analysts must be able to modify processes, rules, and presentation and content. In difference to widespread opinion, process management does not improve business agility by mapping out all activities in flowcharts. That was ok when companies worked the same way for decades. Today companies need to be able to adapt on a weekly basis. The best way to plan and represent a process is by defining the user roles involved, the data entities required and how they are serviced by backend applications, business rules, user presentation and content definitions. Content state drives the process forward.

The problem of complex summary states of content has led to innovative functionality. Consider a software agent who will monitor user activity in a business process (case) and automatically discover the data and state patterns that repeatedly cause user activity.

Conclusion: When BPEL and even BPMN are looked at from a pragmatic business need perspective the only acceptable benefit is that products that use them have similar functionality and people designing processes will find it easier to switch products.  Given that with other products that low level of technology is never touched, that potential benefit becomes a moot point. You can line up BPEL with Java and SOA. Nice idea, but …