Seems like there's been a lot of things going on in the BPM space over the past few weeks. Bottom-line? End-user organizations win as vendors as diverse as IBM, SAP, Capability Measurement, MEGA and Lombardi agree! The BP-* stack is on track... here's a couple of them, courtesy Object Management Group...

Business Process Maturity Model: The OMG formally approved the BPMM specification last week in San Diego. This is a great thing for the industry, as it provides a reference model for measuring a company's journey to process excellence. As you might expect, the primary beneficiary of process excellence is making the people in your company more efficient. Far and away the best way to do this is to reduce rework and improve your ability to estimate results. We're talking doubling the productivity of your people! All of your people... so if you want to put a number on the ROI of BPM, just assume you doubled your revenues with the same number of people and then estimate how Wall Street would value your company. That's what BPM can do, over time, and your progress along this is what BPMM measures. Non-trivial stuff. OMG is really stepping out on this one, as it is a business specification with (seemingly) little technology to implement. Of course, my view is that baking in these measurement strategies is exactly what technology can do, so it will be interesting to see how BPMM informs process management software down the road.

Business Process Definition Metamodel: Also formally approved is the BPDM specification. BPDM has been subject to a lot of hyperventilating so here's a bit of history that, hopefully, puts BPDM in its place, and also lets you know the business value of it, and what you should worry about:

1) As good as it is, the BPMN specification as delivered by BPMI.org (of which Lombardi was a member) was an incomplete spec in that it never defined a way to serialize it (a hifalutin way to say "save it to disk"). It left that up to each vendor who implemented it. Bad idea.

2) BPMI.org merged with OMG about 18 months ago, and a large part of the reason [most of us] chose to merge with OMG was its understanding of model-driven architecture. Specifically, many of the BPMI.org members wanted a standards-based, MOF-based metamodel for BPMN (MOF: a standards-based way to represent model definitions, and a standards-based way to deal with all the things you care about when you save a model definition, like versioning, schema, transformations, etc.)

3) BPMN is assumed by OMG, even though it violates their "rule" that technical specifications have an explicit MOF-based metamodel. BPMI.org members (like Lombardi and BPM Focus) who are interested join existing OMG companies who are already working on a "business process definition metamodel" task force to define the explicit metamodel for business processes generically. The desire to use BPDM as an explicit serialization for BPMN is added to the group's charter.

4) Last week, BPDM is adopted. So now, BPMN has an OMG-adopted standards-based metamodel. In addition to defining the serialization of BPMN in a platform-independent and computationally-independent way, BPDM also adds process notions (such as choreography) that BPMN does not currently support.

5) In June 2007, OMG will be issuing the BPMN 2.0 RFP (essentially the guidelines for a future BPMN 2.0 specification). This will say "merge BPDM and BPMN into one specification." In fact, if and when adopted (probably March '08) BPMN will stand for "Business Process Model and Notation."

6) BPMN and BPDM are technical specifications. They are meant for vendors who are serious about providing robust process solutions that span an enterprise's entire sphere of business processes, which means that they are cross-platform, cross-execution, cross-legacy-system, cross-functional, global environments. BPDM isn't meant to simply "store BPMN into XML." It isn't meant to store only those processes a single engine can execute. It is meant to support many "notations" or views. It's not a specification that you should need to read, any more than you should need to read Microsoft Word's file format specification... but it is able to be understood by many vendors, and across many platforms. There has been some criticism that BPDM is "hard." Well, yeah. For the vendors. But when used, the business benefit is that many tools (provided by vendors who do the hard work) will be able to easily share information. You see, the issue is not whether a specification is "hard" or "easy," but whether the functionality it enables is hard to use or easy to use. And of course, vendors compete in this space. Companies adopting BPDM, like Lombardi and MEGA and others, have an incentive to make interoperability drop-dead easy. We'll do this with BPDM.

7) Why should you care about BPDM then? The only reason to care about any specification is if it drives business value for you. So BPMN & BPDM are important only if you expect to make process improvement an ongoing, enterprise capability. If you're using a BPMS as a point solution for a specific app-dev initiative, they are less valuable (as with any standard, it is when you try to scale across the enterprise that they pay off). As I've explained, BPMN and BPDM will be merging. And, primarily, the changes in the 2.0 iteration will be to BPMN, not BPDM. BPMN will be extended to support the new notions of BPDM, and elements of BPMN will be changed to conform to BPDM. So vendors jumping on the BPDM bandwagon now will have a 1-year head start on the next version of BPMN, which is the primary notation for implementable business processes. So, what's the business value of BPDM? The fact that it represents the next version of BPMN, which is becoming the language for business processes. Vendors who are all about supporting BPMN on top of their process languages (whether those are BPEL, XPDL or proprietary) will be triangulating off of BPDM... the only question is when, and how.

8) BPDM is a huge advance for the industry. Model portability across vendors is pretty important, and this achieves that in a way that is tool-independent (i.e. also notation-independent). The ability for everyone to draw similar pictures using BPMN, and save them using the same file format across tools will expand access to many new users; but the ability to have tools that represent the identical process without diagramming the identical process will move process excellence even further. Concepts like business milestones, as opposed to BPMN activities, for example. In retrospect I wish OMG had simply developed this inside the BPMN spec to begin with... but this does not diminish the value of having this specification approved. We'll correct that mistake over the next year. Until then, let's make sure every one of us vendors moves to this spec... then the move to BPMN 2.0 will be trivial!

9) BPDM was approved by 20 or 30+ organizations at the meeting. The primary contributors to the specification were:

• Adaptive
• Axway Software
• Borland Software
• Model Driven Solutions
• EDS
• Lombardi Software
• MEGA International
• Unisys
• BPM Focus
• U.S. National Institute of Standards and Technology (NIST)

It was a good week for end users, because the notions of business value and, in BPMM, business-facing standardization of process excellence techniques and technologies were advanced.

Technorati Tags: BPDM, BPMN, OMG