Don’t Forget the BPM Ecosystem- Part II

In this post I want to address some address the points raised by Mr. Ismael Ghalimi  in his latest post “Developing a True BPM Ecosystem in response to my post “Don’t Forget the BPM Ecosystem”. Mr. Ghalimi apparently has serious differences with me and I understand where he is coming from. However, I think it is important to address his misconceptions and apparent belief that standards must be applied universally for the success of the BPM industry.

Mr. Ghalimi major contention is that I was looking too macroscopically when I used the example of the transportation industry. He argues that a more sensible approach would be to look at sectors within the transportation, such as autos and airplanes. He claims that if we do that we will find much more standardization and similarities across the sector, and he gives several examples of that in his post.

While I do not agree with his argument, for the simple reason that the term BPM is very broadly used for everything that has the semblance of a process, let us say for the sake of the argument that he is right and look at individual sectors such as autos or airplanes. While Mr. Ghalimi sees similarities and standardization, I see great diversity and lack of standards in these sectors which are much more mature and larger than BPM. For example:

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!


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!



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!


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!

Surely Mr. Ghalimi is not arguing that the aerospace industry would be much better off if it had one set of standards across the industry for all types of airplanes! Doing so is not only unthinkable, but even if someone succeeded in imposing standards by diktat the industry would be stifled as compared to what it is today. The same is true for the BPM industry. One set of standards for cannot be applied across all types of BPM systems that are very different from each other in terms of their goals, transaction volume, criticality, cost and numerous other characteristics.

I do not want to leave the impression that I am opposed to standards. Far from that, I believe that standards are necessary for all industries to be successful. However, standards must be used judiciously where they make sense. Otherwise they lose their value and the market rejects them by never adopting them to begin with. The two guidelines that come to mind for the judicious use of standards in general, and BPM specifically, are:

1.    Standards make sense when they apply to specific products that do very similar things. The more specific the product the higher the chances of adoption and success of standards. For example, in the airline industry one can have one set of standards for jetliners, and another set for commuter planes, and yet another set for small planes. Likewise, in BPM, one set of standards across the BPM industry will not suffice and will not be successful. However, one could have standards for different categories of BPM such as human-centric, system-centric, etc.


2.     Standards make sense when they are applied to “components” and “user interfaces” but not “systems”.  Batteries, screws, tires, parking space size, fuel, street signs are all components and user interfaces. The design of the car itself and the engine is a “system”. BPMN is a “user interface” and that is why it is more successful than any other standard in BPM.

I would like to note that the BPM industry does use a large number of standards for components and use interfaces. These include relational databases, Web Services, the Internet browser, e-mail, portals, AJAX/Web 2.0 and numerous others.

Finally I note that markets (consumers and vendors) adopt standards when their value becomes self-evident to a sizable segment of the market. This implies that the standards have to be relatively simple otherwise the value will not be self-evident. That is why it is more likely to have standards for simpler components rather than complex systems, and BPM falls into the category of complex systems. The BPM industry will be better off if it were to focus its energy on standards for  “interfaces” and “components”, many of which can be adopted from standards widely used in the broader software industry.



1 comment so far

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: