Does BPEL matter?

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 …

Business Process Driven SOA using BPMN and BPEL: From Business Process Modeling to Orchestration and Service Oriented Architecture

Product Description
In Detail

Modeling business processes for SOA and developing end-to-end IT support has become one of the top IT priorities. The SOA approach is based on services and on processes. Processes are focused on composition of services and in that sense services become process activities.

Experience has shown that the implementation and optimization of processes are the most important factors in the success of SOA projects. SOA is so valuable to businesses because it enables process optimization. In order to optimize processes, we need to know which processes are relevant and we have to understand them – something that cannot be done without business process modeling. There is a major problem with this approach – a semantic gap between the process model and the applications.

This book will show you how to fill this gap. It describes a pragmatic approach to business process modeling using the Business Process Modeling Notation (BPMN) and the automatic mapping of BPMN to the Business Process Execution Language (BPEL), which is the de-facto standard for executing business processes in SOA. The book will also cover related technologies like Business Rules Management and Business Activity Monitoring which play a pivotal role in achieving closed loop Business Process Management.

What you will learn from this book?

• Modeling business processes in an SOA-compliant way
• A detailed understanding of BPMN standard for business process modeling and analysis
• Automatically translating BPMN into BPEL
• Executing business processes on SOA platforms
• Overcome the semantic gap between process models and their execution, and follow the closed-loop business process management life cycle
• Understand technologies complementary to BPM and SOA such as Business Rules Management and Business Activity monitoring

Approach

The book provides a well-balanced mixture of theoretical discussion and real-world examples. It explains the concepts and approaches, and describes methodology and notation. It demonstrates these concepts on real-world examples and provides a step-by-step example tutorial that guides readers from business process modeling in BPMN through transformation into BPEL to execution on the SOA process server. It also discusses some key concepts using practical examples and business scenarios around Business Rules Management and Business Activity Monitoring with BPM and SOA.

Who this book is written for?

This book is for CIOs, executives, SOA project managers, business process analysts, BPM and SOA architects, who are responsible for improving the efficiency of business processes through IT, or for designing SOA. It provides a high-level coverage of business process modeling, but it also gives practical development examples on how to move from model to execution. We expect the readers to be familiar with the basics of SOA.

Business Process Driven SOA using BPMN and BPEL: From Business Process Modeling to Orchestration and Service Oriented Architecture

« Previous Page