An Open Letter to OMG-BMI

There has been a flurry of discussion on the Business Modeling and Integration Domain Task Force (BMI-DTF) at the OMG over the direction of development of the new versions of their specifications. Whether BPMN should have choreography capability or not. When BPMN should be linked to BPDM the meta-model and file format behind the notation standard. BPDM has essentially no adoption at this point, but it is still very new so this by itself is not indicative of anything. Yet some of the committee believe that putting BPDM into the BPMN spec will force adoption of this file format. Other feel that the combination will be too complex and possibly will inhibit adoption of the notation part. There have been several comparison between BPDM and XPDL. XPDL is in widespread use, and it appears the commitee members would like BPDM to do everything that XPDL does and more, in a much cleaner way.

The conversation often drifts to “marketing” and “adoption by end-user and vendor communities”. They talk about strategies and air play of their standards. It is as if marketing is some sort of genie that will step in and magically make their work adopted across the marketplace by fiat. To this, I have some suggestions.

Before diving into suggestions, I want to remind everyone that the standards process is driven forward by the huge efforts of a small number of very dedicated people. Most of these people truely want to build something that will be of lasting value to the high tech world. There are always, in any standards committee, a few who attend purely for self interest of promoting their own particular approach to become the recognized standards and then to capitalize on that. Such sheer self interest is ultimately detremental to the success of a standard, and so most successful standards committees tend to weed those people out when discovered. However, let’s assume for this discussion that the vast majority of those in the BMI task force are honestly motivated to develop something that solves a real problem, and such a solution would present a real value to the marketplace. In this case, I would recommend:

• Remember that no amount of “force” will cause a file format to become a standard. A standard must work and must provide a value. If it does not, it will not be used, regardless of how superior the design. Simply linking the file format with the notation in order to force its use will not fool anyone. Combining make sense only if BPDM can stand on its own merit.
• Remain focused on immediate real concerns. One of the more alarming comments was: “BPDM is designed to meet a business need that may not yet be fully appreciated by vendors or customers (who are distracted by proprietary marketing interests).” I would recommend focusing on needs that are appreciated today, or you may not have a chance to tackle the needs of tomorrow.
• Prove that BPDM works in many domains. There is a large body of real processes which are used for real business uses. The standards seem repleat with “toy” processes, such as the example of process between the patient and the doctor’s receptionist. While these are useful to as teaching tools to explain basic concepts, they fall short of actually proving that a meta-model is complete enough to represent the full range of semantics that are required for a real process. To do so, you need a broad coverage of a wide range of different engine types.
• Prove that BPDM is a superset of XPDL. Since XPDL is an XML based language, it is trivial to write a parser, and should not be difficult to write a converter. The exercise of writing this converter will assure everyone that all semantics contained in XPDL have a clear and unambiguous representation in BPDM. You should be able to demonstrate round-trip: from XPDL to BPDM and back, and the resulting file is not degraded from the original. This is in fact a goal for some committee members, but apparently not enough, because not even the specification for such a converter is available today.

My primary concern, without really knowing, is that BPDM is not complete (yet). The internals of XPDL are messy, and that is because real world processes are complex. I can’t count the number of times I have seen committees of people “reject” a defacto standard, in order to provide a far more elegant one, only to find themselves in the end proposing something just as messy as the original. These “new” approaches are often useful in some special case scenario, but are not necessarily able to handle a wide variety of cases. The BMI task force routinely claims that XPDL is a poor approach, but usually without any supporting evidence. It turns out that support for human processes is a very complex and subtle area. There are many different opinions on how to approach this, and those opinions come from different business cultures and customs. It is conceivable that the committee that designed BPDM are aware of only a subset of these approaches. This would be natural and will be resolved only through actual trial in the real world. Showing that one engine can use BPDM proves nothing, except that that particular engine is at least as limited at the standard. We won’t know that the language is complete until it can be demonstrated in use with a wide variety of existing engines.

All concerns would be eliminated with simply providing a BPDM/XPDL round trip converter. A small history lession: JPG raster image format became popular to a large extent because the JPG standard group provided a free tool for displaying and converting images to and from JPG format. Providing such a converter would make BPDM immediately accessible to more than 60 products on the market today. Allowing that converter to be freely embedded into vendor products will allow many products to claim BPDM support very quickly. This is, after all, the goal of the task force: to provide something of value that is adopted by the user and vendor communities.

To those of us wondering whether or not to bet on BPDM: we will know if the committee is serious as soon as they have made available a program that can convert an XPDL file into BPDM, and back again without loss. On the other hand failing to provide such a converter will give every indication to the market of being satisfied to remain an isolated and possibly esoteric file format. My humble suggestion to the BMI DTF is that they make this a top priority because this might be their best “marketing strategy”.