Why Standards Matter

A month ago, the Why BPEL Matters article was posted on IT|Redux, and triggered a wave of discussions rarely seen in the little BPM microcosm. Initially, they focused on arcane mathematical considerations supported by pseudo-scientific arguments on both sides of the fence (here and there). But as the debate progressed, what is at stake for those opposed to BPEL as standard process execution language became clear, and the motivations for supporting their side of the argument painfully evident: disregard for the value of standards, and focus on the needs of vendors rather than the interest of customers (Cf. this article and that one). Let’s take a closer look at what this healthy debate brought under the spotlight.

In reading through these articles (here, here, here, and there), one can see that BPEL opponents are all essentially saying the same thing: “BPEL is an awfully complicated language,” and “I don’t see what BPEL brings to the table.” The first argument is supported by cute little BPMN diagrams and hugly pieces of BPEL code showing how difficult it is to generate valid BPEL code from BPMN flows. The second comes in many flavors, like “BPEL is only supported by a handful of vendors” (IBM, Oracle, and SAP among them, mind you), or “it does not matter what BPMN is translated into, as long as you can execute the process.”

First of all, let us agree with the cohort of BPEL opponents once in a while: BPEL is indeed an awfully complicated language, and generating BPEL code from BPMN flows is not for the faint of heart. We’ve said many times (here, here, and there) that BPEL was never designed to be used by human beings directly. It is to be produced by code generators automatically. Saying that some piece of code is awfully complicated or downright ugly is like saying that a fragment of Java Bytecode lacks the elegance of a few lines of Smalltalk code. Nobody will argue against that, but who should care about it? Nobody. Yes indeed, BPEL is complicated, and so is the generation of BPEL code from BPMN flows, which might be the reason why so very few companies managed to make it work (IBM, Oracle, SAP, and little Intalio). But the same is true for many powerful technologies, like a Java JIT compiler, or a VHDL synthesizer.

Second, let’s focus on the core question, which really is: “do we need a standard process execution language?” Forget about BPEL for a moment, and focus on this question instead. Whatever the standard could be, do we really need one? Answer this question, and the debate is essentially closed. Here, BPEL opponents split into two groups: the ones who could not care less about standards, and the ones who pay lip service to them.

Those who do not care about standards (like Tom Bayens from JBoss, Cf. article), are not only saying that a standard process execution language (like BPEL) does not matter, but a standard notation for business processes (like BPMN) does not really matter either:

“We believe that analysis diagrams can be created in many notations, BPMN being one of them.”
—Tom Bayens, Red Hat JBoss

I thought that BPMN was the one things that we could all agree on. Obviously, I was wrong. That being said, I’m not sure that such a position is considered of the BPM industry at large. After all, it is expressed by someone who works for a company developing tools for Java developers, and these do not care about notations for business processes. All they care about is code, and the only standards that matter to them are the ones defined by Sun and IBM under the Java umbrella. Here again, I will reach across the aisle, and agree that developers do not care about BPMN, and certainly do not want to write BPEL code by hand. Instead, they need a simpler language, and a way to bind it to any programming language (not just Java). This thing is being developed today by the Apache Software Foundation, and is aptly named SimPEL.

Those who pay lip service to standards follow the tradition of the Workflow Management Coalition and only support standards that support the interchange of non-executable models (like XPDL) and interoperability across proprietary products (like Wf-XML). To them, any standard process execution language is a threat, for it would open their niche markets to the competition, and brutally level the playing field. As much as I have sympathy for their fate, I cannot put my Darwinism faith aside. Customer needs matter more than vendor survival.

Keith Swenson concluded one of his articles by asking “Why again do analysts recommend BPEL?” This tells me two things: One, analysts have started to promote BPEL as a standard that vendors must support, and this is great news. Two, the question he is not asking is: “Why do we need a standard process execution language?” Please let me answer this all too important question, for it will be asked again and again.

Validity
Using a standard execution language for processes defined with a standard notation such as BPMN provides a deterministic way of validating the correctness of executables against models. Once the rules that define the translation of a model to an executable have been set and agreed upon, validation tools for code generators can be developed and leverage sets of standard unit tests developed by the industry. Such is the way mature industries like the database industry (SQL) or the electronics industry (Verilog, VHDL) are working today, and the BPM industry should definitely follow their lead.

Predictability
Using a standard process execution language grants predictability for the execution of process models. A given set of standard graphical process constructs enhanced with a proper set of standard execution descriptors will lead to a standard fragment of executable code, in a perfectly unambiguous way. Such predictability of execution is mandatory when processes are used in mission critical environments like air traffic control, military operations, or space exploration (all use cases currently supported by products based on BPMN and BPEL).

Portability
Using a standard process execution language provides portability of executables across process engines offered by different vendors. While portability of process models is desirable at the process modeling tool level, it is not enough without a standard way of translating these models into executables. Such portability of executables is especially important in the OEM market in order to allow Independent Software Vendors (ISVs) to build their applications on top of a process engine. The lack of a standard process execution language would lock ISVs to specific middleware vendors, thereby reducing the appeal of leveraging a third-party process execution engine. To a very large extent, the success of the ERP industry with vendors like SAP and PeopleSoft (now Oracle) hinged on the availability of a standard in the database industry (SQL), and the same will be true for the next generation of application vendors that will look for standards-based platform to build their applications on top of. Similarly, end-customers are increasingly looking for standards-based solutions that will give them independence from any particular vendor, and the ability to migrate their end-to-end process assets from one product to another will become a critical decision factor in their selection of a Business Process Platform (BPP).

Benchmarking
Using a standard process execution language allows process engines from different vendors to be benchmarked against each others, in an objective fashion. While business analysts might not care about things like performance, scalability, fault-tolerance, and quality of service, the people in charge of deploying and supporting the systems that execute business processes do. Without a standard process execution language, benchmarking proprietary process engines is akin to comparing apples to oranges. On the contrary, the availability of a standard process execution language will allow standard benchmarks to be developed. Such benchmarks were developed in the database industry (Cf. TPC), and provided invaluable benefits to customers looking for the database product that would best suit their needs. Similar benchmarks should be developed for the BPM industry, and the availability of a standard process execution language is a mandatory pre-requisite.

Progress
Adopting a standard process execution language will allow the industry to move forward faster, and better address the higher-level requirements of customers looking for ways to implement the vision of the process managed enterprise. The longer the industry debates about which standard is most appropriate for describing executable processes (a fairly low-level question to be sure), or whether such a standard is necessary to begin with, the longer it will take for the industry to tackle the challenges that should come next. To a large extent, the success of the Internet hinged on the availability of a well-accepted standard for exchanging packets of information across computer networks (TCP-IP). This standard was not perfect (some would argue that ATM would have been better suited), nor was it directly useful to business users (I cannot remember the last time I looked at a TCP-IP packet), but it was necessary for a complete stack of standards to emerge, and a plethora of interoperable products to become available. Without such a standard, companies like Cisco or Google would not exist today. The BPM industry needs a standard process execution language. Such a standard exists today. It is called BPEL, it is good enough, and it should be adopted as widely as possible.

The case has been made: we need a standard process execution language. While most industry observers agree that BPMN has estabished itself as the standard notation for business processes, it is not enough to provide a standard execution model for business processes, as explained in this article. In other words, an Executable BPMN Specification can only be defined on top of an executable process language, and the best candidate for such a job is BPEL, also known as WS-BPEL. Once we agree on such an approach, a lot of work has to be done in order to turn the vision into reality. Such an effort is advocated by BPMLab, and outlined in a set of clearly-defined projects. We invite you to join us in this effort.