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.