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.