Should We Design Processes Like Airplanes?

As the ongoing discussion about standards for BPM continues, an interesting thread with Mr. Khan of Ultimus fame emerged. In response to his Don’t Forget the BPM Ecosystem article, I explained that standards always play a critical role in the development of mature industries, and drew further analogy to the airline industry that Mr. Khan felt compeled to challenge in a subsequent article. Unfortunately, his appreciation for the standardization that took place in both the commercial and general aviation markets seems to be fairly limited, and certainly not matched by facts that can be easily observed by any pilot today, myself included.

First, let’s go through Mr. Khan four points:

“i. There is no ’standard’ that I know for the design of the cockpit of an airplane or the dashboard/controls of a car. The cockpit of a Boeing 777 is totally different than that of a Cessna. The pilot’s ‘user interfaces’ are all are different!”

To the untrained eye, it might seem that all airplane cockpits are full of gauges, knobs, and screens that bare very little resemblance to each other when going from one aircraft to another. In reality though, modern instrument panels are the result of a relentless standardization process that makes the cockpit of a single engine Cessna 172 SP NAV III eerily similar to the one of a Boeing 787 (bar the number of circuit breakers). Over the past 3 years, over 95% of new General Aviation airplanes sold in the United States were equipped with computerized instrument panels (referred to as glass cockpits) built using the same technologies as those found in commercial jets, from the Airborne Heading-Attitude Reference System (AHARS) used for positioning and motion control, to the user interface replacing legacy instruments such as attitude indicator, heading indicator, turn indicator, altimeter, airspeed indicator, and vertical speed indicator.

To be sure, such standardization of instrument panels did not occur overnight. It started in the early days of aviation, but accelerated rapidly during World War II in order to facilitate the training of new pilots, allowing them to transition from one aircraft to another more easily. As a result of such a process, most traditional instrument panels (affectionately referred to as “six packs,” for they are built around the same six gauges) look pretty much the same, and any pilot trained on one can very easily transition to another. The same is true today for glass cockpits, which are increasingly using the same UI metaphors for representing standard information such as airpseed (vertical tape on the left), altitude (vertical tape on the right), or attitude indicator (inverted V bar decorated with various visual cues depicting the aircraft’s angle of bank, or the flight director).

And what is true for the cockpit of an aircraft is even more so for the dashboard of a car. The very vast majority of cars sold today display a circular speed indicator on the left, and a circular RPM indicator on the right. Only a handful of exotic cars (from Lamborghini in particular) or electric hybrids (like Toyota’s Prius) have broken away from such standardized analog displays, much like digital wristwatches did in the early 80’s. But if history is any indication, it is likely that analog dash components are here to stay. And the only reason why the RPM indicator might disappear in the future is because it makes no sense on a fully electric car.

“ii. There is no standard that I know for the engine of an airplane or a car. Yes they sometimes look similar, but they are different from each other. You cannot take the engine of one car and drop it into another car. There is no ‘portability’ of the engine. For airplanes of different sizes (a Cessna versus a Boeing 777) even the technologies used are radically different, even though they have many similarities (wings, rudder, landing gear, tail, etc.). The ‘engines’ are all different!”

This isn’t true either. Most mechanics will tell you that with the proper frame modifications, you can take the engine of any car and put it into any other. People do that not only for cars and motorcycles, but for planes as well. Modern aviation knows only three types of engines: piston engine (also called reciprocating engines), turboprop engines (turbines connected to a propeller), and jet engines (using Newton’s law of motion to provide forward momentum through action/reaction, also known as thrust). The former two are largely interchangeable (as long as you keep weights and balances in check), while the later two use the same grade of fuel (Jet-A fuel). In fact, so much standardization took place in the industry that you can mount a car engine on a plane, which is what Diamond did for the DA42 Twin Star, using a pair of Diesel engines originally designed to power entry-level cars manufactured by Mercedes-Benz.

“iii. Mr. Ghalimi mentioned the FAA in his post. I am sure the FAA uses very different standards to determine the air worthiness of a Boeing 777 versus a Cessna. So the quality and inspection standards are also different!”

As a matter of fact, they really do not. The certification procedures are pretty much the same. If you read the Federal Aviation Regulations (FAR), you will see that such certification procedures are not really based on how big the aircraft is, but how it is intended to be used (Part 91 for General Operating, Part 141 for Pilot Schools, Part 135 for Air Carriers & Operators). Even though certifying the Boeing 787 will be a longer and more expensive process than certifying the new Cessna Mustang Very Light Jet, the two certification processes will pretty much follow the same rules. And because the Mustang can be operated by a single pilot, its certification process must have been very similar to the one of the little Cessna 400 I am flying : both are certified for IFR operations, for flight into known icing conditions, and for high-altitude flying (above 18,000 feet).

“iv. You cannot take a pilot of small plane and put him in the cockpit of a Boeing 777 without a lot of training. The training is different!”

Once again, this is not true. All Airline Transport Pilot (ATP) start their training on single engine piston airplanes under Visual Flight Rules (VFR), then transition to Instrument Flight Rules (IF), multi-engine piston, turbine (turboprop), and finally move on to commercial jets. Most professional pilots will tell you that the transition to commercial jets is actually easier than the transition from VFR to IFR. In fact, an IFR-rated pilot (like myself) can get a type rating for Boeing 737 in just a week (Cf. FTI). And if you were to ask any instructor working at Flight Training International (the folks who provide such training), she would tell you that students do not struggle with the aircraft’s instruments or systems (the hydraulics of large jets are pretty complex), but rather with poor IFR proficiency. Staying current as an IFR-rated pilot is where the challenge lies, and this is precisely why so much standardization has been applied in this area, from the notation used for instrument approach plates, to the specification of ground-based equipment used to support such approaches around the world (VOR, DME, ILS, etc.).

Most of the training a pilot receives has very little to do with the aircraft she flies, but rather focuses on the missions to be flown. For example, the pilot of a Cessna 400 will receive the same high-altitude training as the pilot of a Boeing 747 or the pilot of a U2 plane, using the exact same decompression chamber. I followed such a training back in May 2008, at Beale Airforce Base. On my way there, I took a Boeing 747 Captain with me on a Cirrus SR22, and our training session took place immediately after the one given to a couple of rookie U2 pilot dressed in the same kind of suits used by the first astronauts to have been placed into orbit back in the 60’s. This standardized training taught me about the early signs of oxygen deprivation (tingling in the joints, loss of color perception, overall stupidity), all the way to its completely debilitating effects, to the point where I lost useful consciousness (Cf. article). Pretty cool stuff… But my point is: the training of a pilot is pretty much standardized, thanks to the standardization of aircraft and the overall airspace. And that’s a good thing!

After making his uninformed analogies, Mr. Khan goes on writing that standards should only be developed for individual components and interfaces, rather than complete systems. Again, the analogy to the airline industry shows the exact opposite. While very few standards have been developed for connecting heterogeneous sets of instruments to each other, massive standardization has been applied to systems themselves, be they at the aircraft level (as we’ve seen with instrument panels), or at the level of the entire airspace.

Today, the pilot of a tiny Cessna 172 can fly through Los Angeles International’s Class B airspace, alongside a Boeing 747 coming from London and an Airbus A380 on its way to Singapore. When I take a customer or a partner for a Bay tour on Cirrus SR22 (barely larger than a Cessna 172, but a bit faster), we fly directly over SFO, less than 1,000 feet away from heavy jets. And we all follow the exact same rules, fly the exact same approaches (unless the weather is so bad that you really do not want to be flying in a small plane), receive positioning information from the exact same GPS satellites, and use the exact same phraseology, on the exact same radio frequencies. And the same is true around the world, thanks to the adoption of a single language (English) for supporting communications between aircraft and the air traffic control system. The entire system has been standardized, and that is precisely what makes it all work so well.

Granted, such standardization might slow the pace of innovation, as Mr. Khan believes, but it makes the entire flying business a lot safer, and a lot more reliable for passengers. It’s also the only way to make it profitable (although barely nowadays because of the high fuel costs). Such standardization happened in the automotive industry, the PC industry, and even the database industry. While opponents to standardization of the BPM industry are quick to point out that business processes have too much variety in them to bear any meaningful amount of standardization, I would retort that we’re not trying to standardize processes. Instead, we’re trying to standardize the discipline of managing processes (Business Process Management), and the technologies used to do so (Business Process Management System).

Now, anyone should be free to develop and use a non-standard BPMS, much like anyone is free to build and fly an uncertified aircraft. From the FAA viewpoint, such a vehicle is classified under the ‘Experimental’ category, and does not need to comply to most of the requirements that other aircraft do. Unfortunately, experimental airplanes cannot be used for commercial purposes, and have the highest fatality rate of any airplane category. Would you fly such an airplane, Mr. Khan?

Developing a True BPM Ecosystem

In a recent article, Rashid N. Khan, former founder and CEO of Ultimus, makes a case for diversity in the BPM ecosystem, comparing it to the transportation ecosystem. He then goes on concluding that “one BPMS will not satisfy all the process needs of an organization, one BPMS vendor is unlikely to meet all the process needs of an organization, [and] one standard will not be suitable for all types of BPMS.” While I have a great deal of respect for what Mr. Khan did at Ultimus, I must disagree with both his analogy and his conclusions.

Mr. Khan’s analogy to the transportation ecosystem goes like this:

“There are many different systems that must work together in a complimentary manner in order to satisfy the need for transportation. For examples, if an employee has a business meeting in a different city the transportation systems he will use are (a) an elevator to go to the ground floor (b) a taxi to go to the airport (c) an airplane to fly to another city, etc. These systems are all very different from each other. They use different terminologies and technologies. No one vendor offers all of them. It would be foolhardy to apply one set of standards to all of them. However these systems make up the transportation ecosystem and work together synergistically in order to accomplish the business mission. No one expects the transportation ecosystem to be uniform and have the same terminology, technology and standards.”

While this analysis makes sense at a macroscopic level when encompassing all forms of transportation, it falls apart when any major form of transportation is taken individually. For example, transportation based on the use of automobiles would not work if standards had not been set across the entire ecosystem, from the grade of gasoline used in reciprocating engines, to the kinds of bolts used to mount an engine onto a frame, to the signs used on roads and highways. And if you look at any parking lot, you will find a surprising level of uniformity across all the vehicles that can be parked there. Most of them stand on four wheels, have a seat designed for an adult driver on the same side of the car, and a range and top speed that won’t vary by more than 50% across most models. Take any other mode of transportation, be it over airways, railways, or oceans, and you’ll find even more standardization and uniformity. Being a pilot myself, I would never fly on a plane that did not pass a strict FAA inspection for example. And I am willing to bet that you would not either. How about you, Mr. Khan?

The same should be true for Business Process Management. If you take Mr. Khan’s macroscopic view, you might get fooled into thinking that not all processes are the same, especially if you include all kinds of processes, from the creative process of designing a new corporate logo, to the process of settling securities trades, or the process of refining a barrel of crude oil. Granted, these different processes would require very different tools to be managed. But if you focus on the kind of processes that BPM is generally concerned about, those technically referred to as discrete and transactional processes, they all pretty much look the same, and can be managed with a standardized set of tools.

Unfortunately, most legacy workflow vendors have been propagating this myth that business processes can be very different from each other, hence require many different tools to be dealt with. In reality, and having taken a very close look at over 50 workflow products over the past nine years, I must say that most of them do pretty much the same thing, for pretty much the same class of processes. At the exception of niche products optimized for highly specific types of processes (Action Technologies’ ActionWorks for example), most workflow products offer a fairly consistent set of features, and are capable of supporting a fairly consistent set of workflow patterns, as demonstrated by the Workflow Pattern initiative. Nevertheless, they do it in totally inconsistent and proprietary ways. As a result, “BPM standards are lagging, the technology and the terminology is confusing.” Further quoting Mr. Khan, “the lack of clarity and uniformity undoubtedly causes potential customers of BPM to be wary of making investments that could greatly help their organizations. No good business person will invest in any major new initiative if there is a cloud of confusion surrounding it.” While we disagree on the cure, we are in violent agreement on the identification of symptoms.

Whether we like it or not, the BPM industry must go through a consolidation and standardization process if it wants to grow up. Customers looking for BPM products to support their most strategic initiatives are demanding it, and it is our responsibility as vendors to agree on the standards that will make it possible for customers to successfully embrace our products. Such a consolidation and standardization process took place in the database management industry two decades ago, and was largely responsible for the success of the RDBMS as underlying platform for most enterprise applications in use today. And while the RDBMS is not the only way to store data (one could use a computer file system, a paper notebook, or even a human brain to do so), it is the standard way of storing structured and transactional data today.

Finally, the fragmentation of a market into a multitude of vendors promoting proprietary and incompatible products designed to solve a common class of problems should not be confused with a thriving ecosystem. Wikipedia defines an ecosystem as “a natural unit consisting of all plants, animals and micro-organisms(biotic factors) in an area functioning together with all of the non-living physical (abiotic) factors of the environment.” For the BPM industry to be considered an ecosystem, its actors should function together, but they are not today. A thriving BPM ecosystem should be made of enterprise modeling tool vendors offering integration with BPMS vendors through a standard like BPMN, Business Intelligence (BI) vendors providing the most advanced Business Activity Monitoring (BAM) and Business Performance Management (the other BPM) tools tightly integrated with BPEL-based process engines, and armies of consultants trained to BPMN and BPEL taking advantage of these interoperable, standards-based products. Should we fail to establish such standards, customers will invariably turn to vendors of integrated stacks like IBM and Oracle (Cf. Dennis Byron’s article), and lose all negotiation power along the way.

Developing such an ecosystem is very much a part of BPMLab’s vision, and we invite you to join us in this effort.

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.

What is BPM 2.0?

BPM 2.0 is a term originally coined by Bruce Silver (BPMS Watch) and defined by Ismael Ghalimi on this post. The concept was later refined through this other post. Many industry analysts agree with this definition, including its reference to WS-BPEL, which we believe is a requirement for the development of an executable BPMN model (Cf. BPMI.org Redux). What follows is a summary of its guiding principles.

Please let us know what is missing, or what might be unnecessary.

BPMI.org Redux

This article is an unedited version of this original article posted on IT|Redux.

A breakthrough, finally! After almost a month of back and forth discussions started by the now-infamous why BPEL matters post, and continued on InfoQ, the Workflow Patterns Google Group, and countless posts on this very blog, we finally reached a conclusion, drawn by Bruce Silver and relayed by David French. They are calling for the industry to develop a “Compliance Specification for BPMN” that would define the “elements, attributes, and flow patterns that must be supported to claim BPMN support.” What a great idea! Now, let’s take a look at how such a specification should be developed, and who could take the lead for such a project.

As of today, several things are missing to make BPMN a true standard in the industry. First, as Bruce Silver pointed out, BPMN’s semantics are “vague” and need to be clarified, especially with respect to the elements of the specification that should drive the generation of executable processes. Second, there is no standard interchange format for BPMN diagrams that would allow a diagram designed in one tool to be used in another. Third, if BPMN is to be used as overarching framework for describing executable processes, all “annotations” to the specifications that are required to turn a pretty picture into an executable process should be standardized as well, as well as the way to serialize (translation: translate into textual form) all these annotations.

To a certain extent, all this refers to the vision of “native BPMN engines” that has been promoted by some vendors lately. While the vision looks good on paper, what these vendors fail to realize (or advertise) is the fact that BPMN only deals with one dimension of processes: the flow of execution. But it totally overlooks another critical dimension of processes: data. How data flows through the process, how it is exchanged between processes, how it drives the execution of business rules throughout the process, etc. And guess what? Properly adding this data dimension to BPMN will lead to the complete re-invention of something that already exists: BPEL. So why not start from it, by using BPEL as default execution model for executable BPMN processes?

What Bruce and David call a “Compliance Specification for BPMN,” I would refer to as “Executable BPMN Specification.” It would unambiguously describe the elements, attributes, and flow patterns that must be translated into BPEL in order to support proper execution, and the ones that are there for documentation purposes only. With respect to the former, this specification should formally describe which BPEL code must be generated for which elements, attributes, and flow patterns, making the underlying BPMN to BPEL code generation fully deterministic and predictable. Such an effort should be supported by the proper formalisms, leveraging recent scientific papers such as the Formal semantics and analysis of control flow in WS-BPEL by Ouyang, Chun and Verbeek, Eric and van der Aalst, Wil M.P. and Breutel, Stephan and Dumas, Marlon and ter Hofstede, Arthur H.M. (2007).

In parallel to this effort, a group should work on a standard serialization format for BPMN. This format should be based on XML, canonically map the BPMN diagram’s graph structure, and be fully extensible so that vendors could add their proprietary decorations to it (font attributes, shape colors, icons, etc.). That’s the easy part. The difficult part is in understanding that we need two serialization formats, one for non-executable BPMN, and one for executable BPMN, the former being a subset of the later. A serialization format for non-executable BPMN can be developed right away, and should be a fairly straightforward exercise. All it would require is a thorough review of the current BPMN specification, and a fair amount of discussions among tool vendors in order to define the mechanisms by which the specification could be extended in order to support proprietary decorations. A serialization format for executable BPMN would not only require the completion of the first specification (for non-executable BPMN), but also the completion of the Executable BPMN Specification as well. Eventually, the three efforts should be combined into a single specification.

If this makes sense to you, please let me make some recommendations:

Properly define both ends of the equation
If your goal is to define a specification for executable BPMN, make sure to define what “executable” means, and there is no easier way to do that than by picking an execution language that already exists. As of today, BPEL is the most complete, most robust, and most widely supported, hence should be considered as the best candidate. Furthermore, this default execution language should be the only one you care about. The minute you start adding other options (like XPDL), the project goes off tracks, for you need to define an unnecessary abstraction layer. You go from meta to meta-meta, then from meta-meta to meta-meta-meta, and before you know it you pulled a German dictionary from your bookshelf in order to understand what über-meta means. Instead, just consider this exercise as solving an equation. For the equation to be solvable, you need to define both ends, BPMN on one side, BPEL on the other. Once you solved the equation, feel free to add variations to it, and see if the work you’ve done could be used with other target execution models (like XPDL). But make sure to solve the original equation first!

Do not worry about round-tripping between BPMN and BPEL
Round-tripping is a futile and wasteful exercise when attempted between two languages or notations that have a significant semantic gap between them, and so is the case for BPMN and any process execution language optimized for computers (like BPEL). The same is true between UML and Java by the way. Round-tripping should be set as a goal only between two languages or notations that are essentially representing the same thing, such as BPMN and its future serialization format for example. What this means is that there must exist a way to fully serialize BPMN diagrams on one hand, and a way to graphically display serialized BPMN on the other. And all this should work in a deterministic and predictable way, uniformly across tools.

Do not worry about the ugliness of the BPEL code
BPEL is to be produced by code generators and consumed by process virtual machines, not written nor read by human beings, so do not pay attention to the verbosity of the BPEL code resulting from the translation of executable BPMN. Of course, the BPEL code should be correct and as succinct as possible so that we can more easily apply formal validation techniques to it, but do not try to make it any simpler, for there is no point to it.

Improve BPEL whenever necessary
As many pundits indicated, some BPMN flow patterns cannot be translated to BPEL. In some cases, it’s because they should not, for the BPMN diagram is wrong — as in, it makes no sense at all. A smart BPMN modeling tool should detect such flawed patterns, and warn the business analyst that while beautiful, this flower-shaped graph is utterly meaningless. In other cases, the BPMN diagram is simply representing something that will not be executed by any kind of IT system, and no BPEL code should be produced. In yet other cases, the BPMN diagram can be translated into BPEL, but the resulting BPEL code will be ugly, and it would be preferable for the business analyst to change the BPMN diagram slightly in order to support cleaner BPEL code generation. A very smart BPMN modeling tool should detect such occurences, and make suggestions that could improve both the BPMN diagram and resulting BPEL code. Last but not least, in a few cases, the BPEL language might not be powerful enough to represent some BPMN constructs. I have yet to come across such instances, but let’s assume that they could arise, just for the sake of the exercise. If such were to be the case, take note of the limitation, and send it to the authors of the BPEL specification. If they do a good job, they might address the limitation you found in a subsequent version of the specification — BPEL 3.0, anyone? In the meantime, the non-executable pattern you stumbled upon should be added to the non-executable BPMN section of the specification, and marked as “not yet” executable.

If you follow these guidelines, you might get something out of the exercise.

Now, how do we get there? Well, if I’m the only one thinking that such an exercise would benefit the industry, there is not much point continuing the discussion, and all we need is for Intalio to better document the way we translate BPMN into BPEL. We already have a serialization format for BPMN (we donated it to the Eclipse Foundation), and we already generate valid BPEL 2.0 code for pretty much any BPMN diagram that makes sense.

But if there are other people out there who think that vendors and customers would both benefit from such a set of standards, we better start working on them now, and this begs the following question: where such a piece of work should be conducted? Which standards organization should host it? Should we propose it to an existing one, or should we create an ad hoc organization from scratch, and run with it?

Well, I have a fair bit of experience in this area, having founded the Business Process Management Initiative (BPMI.org) back in 2000, and chaired it for about four years. I have helped orchestrate its integration within the Object Management Group (OMG), and remotely followed their work for the past few years. I have also witnessed the evolutions of the Workflow Management Coalition, the W3C, and OASIS, and learned a few things along the way. From all this, I can safely say that the proposed exercise will fail if it is not conducted within a new group, which sole objective is to make it succeed.

I will leave to others the task of discussing why the aforementioned organizations are not suitable candidates for hosting such a project, and will just explain where the challenge lies: in trying to build this executable BPMN model, one has to bridge the gap between two specifications that are owned by two different groups: BPMN owned by the OMG, and BPEL owned by OASIS. Furthermore, this work has to be done in isolation from other specifications which integration would lead to failure, first among them XPDL owned by the WfMC. To make it perfectly clear, I have nothing against any of these fine groups of people, or the specifications they produced. I have strong opinions about their usefulness, but these should be for me to keep. The only thing I care about is the success of the project, for it will take significant resources to complete, and these resources do not come cheap, especially today.

So here is what I am proposing. If you’re interested by the notion of executable BPMN and believe that the easiest and fastest way to get there is to build it on top of BPEL first, then I invite you to join us (Intalio and a few others) in the creation of a new group tentatively called BPMLab. It will be a non-profit organization managed like the BPMI.org of the early days, which mission will be to develop standards for BPM. Membership will be open to anyone, will be affordable, and will get you in touch with people who share the same passion about BPM as you do. But make no mistake, BPMLab won’t be an advocacy group for BPM, or even less a place to learn about Business Process Re-engineering. There are plenty such groups out there, and there is very little we could add to their work. Instead, BPMLab will be a group of experts who can make meaninful contributions to the field of executable BPMN, in a constructive and pragmatic way.

BPMLab, anyone?

Why BPEL Matters

This article is an edited version of this original article posted on IT|Redux.

Following my recent post on BPM 2.0, Sandy Kemsley, one of the few independent analysts covering the BPM space, was quick to agree with our updated definition of BPM 2.0, at the exception of one point (out of sixteen): support for BPEL. The question of BPEL vs. XPDL, (or BPEL vs. nothing) has been one of the most debated topics in the decade-long history of BPM. Here is why BPEL matters.

First, let me make something clear, once and for all: nobody should ever try to write BPEL code by hand, unless they really have to. As far as I’m concerned, the ones that really have to are employed by BPM vendors whose products support BPEL. BPEL is an extremely powerful yet very complex language, and I don’t think there are more than a few hundred people around the world who can write decent BPEL code by hand. BPEL is a precise yet verbose language that was conceived to be produced automatically by code generators, not written by hand. In other words, BPEL is for computers, not human beings, at least not the ones I usually hang out with.

Second, should you really want to write code by hand, you should use a simplified version of BPEL, based on a less verbose syntax, and such a language is currently being developed by Intalio as part of the Apache ODE project. It’s called SimPEL, and it’s something that Ruby or Ruby on Rails folks will love.

Third, should you not want to write any code, you should move a step up the stack, and produce your BPEL code with a BPMN designer rather than a visual BPEL editor. The reason for it is pretty simple: BPEL is a complex language because of its semantics, not just because of its verbose syntax (which makes it complicated, but not necessarily complex), and a visual BPEL editor does very little to alleviate this complexity.

Now that we all agree that we should stay as far away from BPEL as possible, why on Earth does it matter that the core process engine runs BPEL code vs. XPDL, Java, or any proprietary process execution language devised by some BPM vendor? There are very many reasons for it, so let’s go through them one by one.

BPEL won the war of standards
Whether you like it or not, BPEL won the war of standards. While we (Intalio) lost a battle when BPML was supplanted by BPEL (because we had failed to secure IBM’s support for it), the war was eventually won when BPEL 2.0 was released (with Intalio’s support), and all major vendors adopted it against XPDL, including Microsoft, Oracle, and SAP. Some legacy workflow vendors might find delight in trying to re-play lost battles of the past (like some nostalgic French patriot dreaming of what could have been had Bonaparte’s army won the Battle of Waterloo — I know, I’m French), it’s time to move on. Really.

BPMN is not enough
Many people who fought for XPDL five years ago are now promoting the idea that neither BPEL nor XPDL really matters, and that all we need is BPMN. After all, BPM is for business analysts (wrong), and all they care about is what the process looks like. This argument is disingenuous at best. Executable processes cannot be designed with BPMN alone. A BPMN diagram is the process’ skeleton. For the process to walk (or run), it needs flesh around its skeleton. BPEL is the DNA that is used to produce it. Pick the wrong underlying language, and you end up with the wrong DNA. What’s missing in BPMN for it to describe executable processes? Data. Why is data important? Because a process without data is like a living being without language: it might walk or run, but it can’t speak nor listen. If your BPM vendor of choice is advocating that only BPMN matters, they’re using proprietary ways to make your processes fully executable, usually requiring a lot of custom code development, and this is the last thing you want for your processes. Whenever you find yourself listening to such a misleading marketing pitch, simply ask the following question: “Can you show me the code behind the boxes and arrows?”

BPEL is built upon the right mathematical model
A BPM vendor has three options to make processes executable: BPEL, XPDL, or their own language. If they use BPEL, they’re leveraging the Pi-Calculus mathematical model for supporting the execution of distributed and collaborative processes, taking advantage of one of its very powerful features, channel passing. If they use XPDL, they do not benefit from such a capability. If they use their own language or execution model, they do not benefit from the academic work that is validating and strengthening existing standards.

BPEL supports distributed transactions
Thanks to the notion of Scope, BPEL 2.0 supports distributed transactions that can be executed through the battle-tested two-phase commit protocol. Neither XPDL nor any proprietary process execution model I know of supports it, which makes them unsuitable for a broad range of enterprise applications. Again, you could hard-code distributed transactions within software components like Enterprise Java Beans, but this is not BPM (at least not BPM 2.0), it’s old-school OLTP.

BPEL is the standard
BPEL won the war of standards, and as such became the industry standard, and standards matter. You might not care to know about them, but you definitely care to know that your system is built on them. If you own a car, you’re glad that it’s running on standard gasoline, and that you can get your refill at any gas pump, operated by any oil & gas company — even though you hate the fact that gas is so expensive nowadays. It’s the same for a BPMS. If it’s built on top of BPEL, you’ll be able to take the processes you designed with its tool, and run them on another vendor’s engine. You cannot do that with a BPMS built on top of a proprietary execution model. Saying that BPEL does not matter when selecting a BPMS is like saying that SQL does not matter when selecting an RDBMS. Who in their right mind would buy a database engine that does not support SQL today? Why should it be any different with BPM and BPEL? This totally escapes me.

Executable BPMN does not exist
Whenever challenged with the argument above, non-BPEL vendors make the point that BPMN is all you need, and that executable BPMN is coming soon. Supposedly, OMG’s BPMI.org is working on something like that, and if you read the Business Process Definition Metamodel (BPDM) with a strong-enough dose of wishful thinking, you might find it between the lines of this arcane specification that nobody supports. Reality is, there is nothing like executable BPMN, and should anyone develop such a thing and did a good job at it, they would end up re-inventing BPEL 2.0, or something very close to it. In other words, the combination of BPMN and BPEL is all you need to make processes executable. The two members of this duo play very nicely together, but separate one from the other, and the whole thing falls apart.

Welcome to BPMLab

Eight years ago, I founded the Business Process Management Initiative (BPMI.org), which aim was to develop standards for Business Process Management (BPM). In the early days, it largely succeeded, and delivered the Business Process Modeling Language (BPML) and the Business Process Modeling Notation (BPMN). Eventually, BPMI.org merged within the Object Management Group (OMG), and did not manage to innovate beyond the release of BPMN 2.0. BPMLab is an attempt at continuing BPMI.org’s original effort, developing an integrated stack of standards for BPM based on BPMN and BPEL.