Ryan Armasu is one of the most avid readers and commentators on this blog. Two days ago, he posted a comment to the BPM 2.0 is Middle-Out article that essentially said: “we need a standard model for BPM 2.0.” Without any warning, this comment took me six years back, when Howard Smith and I created the Business Process Management Initiative (BPMI.org, now part of the OMG) in order to develop a standard model for BPM (1.0). Here is a transcript of Ryan’s post, followed by my personal thoughts on the subject.

“Ismael, Bruce:

Do you think maybe it’s time for experts such as yourselves to get together and establish a standard model for BPM 2.0 in simple, concise and hopefuly universally applicable terms that can be ported throughout various functions and industries?

My work is in the supply chain arena, where about 10-15 years ago there was a similar debate regarding what constitutes a supply chain, which business function was responsible for what portion of the chain, what were some characteristics unique to the supply chain, but standard enough that could be used across all industries, etc… you get my point.

On that background, a number of experts and major clients in the supply chain arena got together and formed the Supply Chain Council, with the mission of developing a standard model, performance metrics and best in class practice, which they called the Supply Chain Refernce Model, or SCOR.

This maybe be to a certain extent what BPM 2.0 needs — a standard model, the basic tenets of which all experts agree on. A model that is relevant to all parties (Business and IT), yet simple enough that it can be easily understood by all involved, so that its use is being promoted by the debate, and BPM’s adoption rapidly expanded.

SCOR is such a model in my area of expertise, and I can tell you that by its development and use modern supply chain concepts were easily and widely adopted by practitioners.

Just a thought.

-Ryan Armasu”

First of all, I must say that I agree with everything Ryan wrote. We need a standard model for BPM, complemented with a set of technical standards for it. This is exactly what we tried to do with BPMI.org. Unfortunately, our poor marketing skills (and resources) did not allow us to prevent fragmentation.

BPML was eventually replaced by BPEL, and no strong ties were established between BPMN and BPEL, creating more confusion than was necessary. BPMN ended up at the OMG, while BPEL was developed by OASIS, without much communication between the two groups. Today, very few vendors have adopted both specifications.

Traditional workflow vendors and workflow-oriented BPM pure-plays claim that BPMN is all they need, while SOA-oriented folks promote BPEL, but do not provide any tools that are usable by business analysts. The status quo has been extended for another five years, to the benefits of the larger players. And customers are left asking themselves what BPM really is, and what it can do for them. Like it or not, standards would help clarify the situation, and this is exactly where Ryan’s point makes perfect sense.

Now, is it time to create a standard model for BPM 2.0? Do we want BPMI 2.0? Do we really want to create yet another standard body? To be honest with you, I don’t know. I know what it takes to create such a thing, I have done it before, and it’s hard. Standard bodies require consensus among participants, and the easiest way to create consensus is to adopt the largest common denominator. Problem is, the largest common denominator is by definition smaller than the smallest common multiple, and usually pretty small. Translation: most standards do nothing, because after years of discussions, the common ground got reduced to a tiny lot of land that nobody really cares about.

If I were to create a standard model for BPM 2.0, I would start by defining what it is, without trying to re-invent the wheel, and the quickest path toward this would be to start from the BPMN and BPEL specifications. Take BPMN and BPEL, figure out what this gives you, then describe a set of benefits that business and IT users would get out of it. Again, I would adopt this middle-out approach which seems to work best when trying to bridge the business|IT divide.

Then, I would try not to repeat one of the mistakes we made with BPMI.org, which was to focus exclusively on the technical side of things, without paying much attention to the need for education. So I would make sure that two parallel tracks would be developed, with equal amounts of resources.

One would address technical requirements, such as the definition of a clean serialization format for BPMN and a proper meta-model to link BPMN and BPEL. The other would focus on evangelization, educating business and technical users alike, with a keep-it-simple-stupid marketing message.

For business users, I would try to debunk the myths of BPM 1.0, explaining why business analysts cannot do everything by themselves for example. Sorry Mr. Customer, you still need some IT folks… And for technical users, I would illustrate how BPM is SOA’s killer application, while SOA is BPM’s enabling infrastructure. I think they would get it fairly quickly if multiple vendors were to speak with a common voice, and put their differences aside for a minute or two.

I do not know if I am really up for it, but if enough vendors and users are willing to give it a shot and dedicate proper resources for such an initiative, I think I could be convinced to go for it again. And if not, we’ll just keep doing what we’ve been doing recently, which is to prove that the whole thing works, with an implementation that everybody can use for free.