Why is there all this concern about a single process standard? I was reminded of this while reading a recent article in “Viticulture Obscurant” about a similar situation in Elbonia with standardization of the broad range of wines, which I reproduce in full below:

——-

Elbonia – July 16, 2007 – Citizens and government officials of the republic of Elbonia have been up at arms, almost literally, about the bewilderingly large number of varieties of wine that are now available on the market. There is a growing movement to limit the number of varietals that can be sold in order to simplify the act of ordering dinner at the local restaurants. The diners’ complaint is that it is tremendously difficult to match the right wine with the right dinner because there is simply so many choices.

“The wine list at my favorite place has Cabernet Sauvignon, Merlot, Pinot Noir, Cabernet Franc, Grenache, Malbec, Montepulciano, Shiraz, Zinfandel, Petit Syrah, Sangiovese, Lambrusco, Dornfelder, Bovale Sardo, Schwarzriesling, Ruby Cabernet, Tinta Barroca, and Preto de Mortágua and that is just on the red list.” says the town Mayor Harrison. “It is difficult enough to pick from all these in the first place, but it gets worse when you consider vintages. You have to keep track of which years are good for which regions. What we need is a single wine that everyone can have for every occasion.”

This sentiment is reflected in a new standardization efforts on multiple fronts. One such group produced the Border Practice Multi-Index to define the way that a wine should look, smell, and taste, even though this group does not actually produce any wine. A representative commented: “We did not want to show favoritism to any particular variety so we took the best qualities of all wines, and came up with standardized descriptions. So when someone says that the wine has a ‘musty nose’ or that the ‘bouquet includes blackcurrants, eucalyptus, chocolate, tobacco’ we will all know exactly what they mean.”

The index however has been criticized because it still allows multiple varieties of wine to exist. One restaurant critic complained, “I thought the index was supposed to define the qualities of the perfect wine. A vineyard would then simply create a wine with all the correct qualities and you would have a wine for all occasions. If a vineyard produced a wine with some of the qualities, and not others, consumers could simply boycott that wine until it got the required components. That way all wine would be perfect for any occasion.” There is disagreement about whether this was the goal of the index in the first place.

A different group represented by the two largest grape growing regions got together to form the Basque Puncheon Evaluation League and decided that “Chardonnay” would be the single official wine in the industry. “I have had many many good meals with Chardonnay, and they all have turned out great! I really have never had any reason to drink any other wine. Besides, all those other flavors really confuse me and I find it easier to stick with a wine I know.”

Since that time, an entire sub industry has grown up offering “Chardonnay-only” wines, and producing recipe books that feature the varietal in cooking and serving of all kinds of cuisines. Wine masters have written well-received books saying that ‘the perfect meal starts with a layer of Chardonnay as the foundation.’ It seems almost as if nothing can go wrong as long as it has Chardonnay in it. When local diners ask their sommelier why Chardonnay was the chosen varietal, the answer given, after a brief look of vague hopelessness, is “because the two largest grape growing regions chose it, so we know it is going to be successful.”

While clearly simplifying the wine lists, this move is not without its detractors. One buvionist, speaking under conditions of anonymity said “The problem is that even though all these wines say they are Chardonnay, the don’t taste the same! Each vintner makes the wine in a different way, putting their own special enhancements to it, and the result is that each Chardonnay has a distinct taste. The original point was to have a single wine for all occasions. How is this achieved if they are all different?”

Sceptical of Chardonnay’s ability to meet the needs of every meal, an irrepressable band of vintners continue to produce red wines in the traditional ways. In spite of the desire for a single wine for all occasions, people have continued to enjoy red wines as well as other varieties of white wines. This has not gone completely unnoticed, and in a surprising move a number of Chardonnay vendors have acquired significant holdings in red-grape vinyards, clearly with the intent to enhance their line to include both white and red wines.

Even more suprising is the announcement from a group known as Winesap Blue for People who have announced a new varietal called “Chardonnay Dark” which is based on Chardonnay (and therefore the perfect ingredient for any meal) but includes many of the features of a fine red wine. The acolytes praise this move to finally provide a single wine that is good for all occasions. A prominent Elbonian wine enthusiast had this to say: “I tried the new Chardonnay Dark, and I really liked it. In the bouquet I detected hints of blackcurrants, eucalyptus, chocolate, and, yes, even tobacco! I expect to be drinking this with every meal in the future.” Unfortunately the wine will not be available for a few more years.

At the same time, and probably unrelated, is a new development called the “Omni-grape” from the Borg Province Dept of Metamagic. The omni-grape is a variety of grape that contains all flavors of all possible grapes. “With a vinyard full of these grape vines, you can decide at harvest time what kind of wine you want.” The technical literature about the grape only includes instructions for making Chardonnay, but we have been assured that all other wines can be readily produced, as soon as representative of those other varietals get around to defining the mappings. While this is clearly an important development, it has been criticized for not actually simplifying the final wine list.

So the situation is far from resolved. Every evening, Elbonians continue to face a daunting task to determine their libation. While some restaurants now offer the simplified Chardonnay-only list, it does not seem to have the overall effect that was promised. However there is hope that new standardization efforts are continuing so that one day, in the not too distant future, diners will be able to sit down to a satisfying meal without ever looking at a wine list.

—————–

It struck me that there are some surprising parallels between this situation and the one we find ourselves in the area of Business Process Management. By drawing this parallel, I do not mean to say that there should be as many process languages as there are varieties of wine. But I do mean to draw attention to how questionable it is to be hunting for a single process language for all situations. Different process languages are fit for different purposes. Work in an office space is complex. There are no simple solutions for that complexity, but still people yearn for a simple solution. We should instead focus how well a particular language worked in a particular situation.

Going to be at BPM Think Tank? I will. Maybe we can discuss this over a glass of something-that-is-not-Chardonnay.

Queensland University of Technology is doing a survey on BPMN Usage. Anyone that uses BPMN to create process models for whatever purpose is welcome and encouraged to participate. These guy in general are doing a lot of good work for BPM, so I assume this is another worthwhile endeavor. Here is the info:

BPMN is gaining momentum in practitioner communities, up to a point that even those vendors who were initially reluctant to adopt it, can no longer completely ignore it. But what exactly are the factors that drive this acceptance? How satisfied are end users of BPMN with the notation? Do user experiences on BPMN match those by BPA tool vendors?

Jan Recker from the BPM Research Group at Queensland University of Technology is undertaking a worldwide survey on the use of BPMN by process modellers to shed light into this question. You can help Jan by completing the survey available here:

http://www.bpm.fit.qut.edu.au/projects/acceptance/survey/BPMN/

The best way to contact Jan is via email: j.recker@qut.edu.au

The next BPM event will be happening May 21 through 24 in the Washington DC area at the Transformations and Innovation conference.

It starts with one day workshop on May 21 on “BPM in Practice: Understanding and Implementing Workflow and Business Process Management” given by key members of WfMC. To be covered are:

• BPM 101
• BPM and Enterprise Architecture
• Human BPM compared to EAI Processes
• Business Process Analytics
• BPMN overview
• XPDL overview
• BPEL overview
• Wf-XML overview
• Summary and open questions

It is designed to be a comprehensive overview of the BPM space for those new to the subject and wanting to get their bearings, and also for those familiar with the subject who want to big a bit deeper through direct interactions with the people who have been working on the standards. See the brochure.

Also BPM Focus will be there with a session on Enterprise Architecture.

I just got my copy of the 2007 issue of the Workflow Handbook, and this looks to be the best issue yet.

Finally something useful: a BPMN poster:

Claims to have everything you need to know. It certainly contains a lot of useful info. It is from the University of Maribor, Faculty of Electrical Engineering and Computer Science, Institute of Informatics, in Slovenia. The authors invite comments, and I imagine a comment on this post will get them.

I got a comment on my last post which so obviously misses the point so much of the discussion around these standards, that I half suspect this Anonymous post was a practical joke from a colleague for the amusement of watching me get defensive.  However, lets assume that the poster was sincere, and respond to anyone who might hold a similar point of view.

Arguing that BPEL is “more” or “better” than XPDL is like arguing that red is “more” or “better” than blue.  Like arguing that apples are “more” or “better” than oranges.  Like arguing that a race-car is more or less useful than a jeep.

Consider an analogy of two file formats: one for documents (e.g. Microsoft Word) and one for presentations (e.g. Microsoft PowerPoint).  If you look at a list of “brochure points” these different product categories might seem very similar: they both support fonts and word-wrapping, they both support pagination, they both have the ability to draw graphics, they both can do tables, they both can display full screen, they both have spell checking, they both support hidden comments, and so on.  Yet you might assemble a room full of people;  on one side would be the technical writers, journalist, novelists who would point out how the document format is clearly superior and more useful to them, and they would be right.  These writers might say that they have the presentation software, but just use it to make graphics to paste into the documents, and overall the document format is of primary importance.  Yet on the other side of the room is a bunch of presenters, lecturers, teachers, and (dare I say it) politicians.  This side claims that is the presentation format that is far more useful and powerful;  while they keep the document processor around to read files they occasionally find on the Internet, they really only need the presentation package to do their work.  If such a debate were considered seriously, it could go on forever getting more and more detailed about the fine points of word-wrapping, spell-checking, animation, pagination, etc.

Hopefully this analogy makes it clear just how silly such a debate would be.  There is no war between document processors and presentation graphics packages.  Yes, there is a certain overlap, but the only thing that the debaters are proving is that they have different goals for what the software should do.  There is no reason to believe that adoption of a document format will necessarily cause the exclusion of a presentation graphics format.  They are different things used for different purposes.

Just to make things perfectly clear, I never said that BPEL was less important than XPDL.  I never said that BPEL would in any way be replaced or supplanted by XPDL.  BPEL is an important standard that does what it does, but utterly fails to what XPDL does, because it is simply a completely different thing.  There is no war between XPDL and BPEL.

For example, draw a process diagram, lay the nodes and lines in particular positions, write it out to BPEL, and read it back in.  It is impossible to get the same diagram back in because BPEL simply has no way to preserve node positions and line positions.  Arguing that you don’t NEED the lines and positions to be preserved brings us with circular logic back to our starting point: BPEL and XPDL are designed to satisfy different needs.  XPDL, on the other hand, represents the graphics of the process, and when you read it again you end up with the same diagram.

Let me illustrates the differences between these different standards in a more concrete way.  I will have to use a very simple diagram, and a simplifications of the BPEL and XPDL output, so bear with me.  Consider the following BPMN diagram:

What do you see?  On the surface, you see six shapes: two circles, two diamonds, and two rounded rectangles.  You also see six lines (with bends in them) that connect the shapes.  Those lines have arrows to show the direction of flow.  If you understand the symbols in BPMN, then you understand that this diagram is showing that after the process starts, there are two activities: Activity1 and Activity2, which execute at the same time.  The process will complete only after both activities are complete.  See how there are two ways of thinking about the picture, one is very superficial and includes the specific shapes, the other attempts to include only the underlying meaning.  This is similar to the distinction between BPEL and XPDL.

BPEL attempts to capture only what the execution engine needs to know: the two activities and the fact that they need to be run in parallel.  In BPEL, if you want to activities to run at the same time, you nest the activities inside of a <flow> tag.  The flow tag says that everything inside of it will be executed in parallel.  A highly simplified BPEL output might look like this:

In a certain sense, this is all that an execution engine needsto know.  The two invoke activities will be launched in parallel, and the process will not complete until both invoke activities are complete.  But if you try to read this back into the process modeler, you will find that you can construct something that looks very much like the original (because the AND gateways can be added in because they are logically required, and the arrows between them are logically required) but you can not guarantee that the diagram will be the same because the graphical information is simply not there in the file.  Note that BPEL has no way to directly represent a line in the diagram, and it does not need to, since lines are not executed, they simply show the relationships of things.

The XPDL representation would be decidedly different.  XPDL represent the process model, not simply what is needed to execute the process.  It will have six activity tags to represent each of the nodes (in XPDL the term “activity” encompasses all of the BPMN nodes: activities, gateways, and events) and it will have six “transition” tags, one for each line.  The graphical coordinates for the nodes can all be saved, and the points for the lines, including details of precisely where the lines bend and where they touch the nodes, is included in the Transition tag.  A simplified version might look like this:

Above is a direct representation of the process diagram, not the abstracted meaning behind the diagram.  It should be obvious to everyone that you can read the XPDL file, and recoverthe exact same diagram that you saved.  XPDL is a direct one-for-one representation of the BPMN diagram, and all the additional attributes associated with the diagram.  BPEL, on the other hand, is a one-way transformation; the translation is a “lossy” translation because it does not contain all the details of the diagram.  It was never designed to do this, so there is nothing wrongwith this, it simply is something that BPEL does not do.

Saying that  “BPEL is more portable than XPDL” simply tells me that all you care to communicate is the execution meaning of the process.  It tells me that you do not care about, and possibly have never tried to transfer a process diagram of any complexity.  If all you need to do is to communicate process execution semantics, then by all means continue to use BPEL – there is no reason to think you should be using XPDL for this.  They are, after all, completely different standards designed for completely different things.  However, your experience with interoperability is not commonplace.  John Evdemon, co-chairman for the WSBPEL working group at OASIS, asked the attendees of last year’s BPM ThinkTank whether anyone was using BPEL for interoperability between products.  When nobody raised their hands, he used this as evidence to support the claim that “the portability of executable BPEL will be low to non-existent“.  It is a strong claim, and the head of the working group should have as much experience as anyone in the subject.  But if it works for you, that is great. 

I personally believe that eventually BPEL will offer great value to all of us, and I support its adoption for the things that it is capable of doing.   At the same time, so does XPDL, which is capable of exchanging of process definition diagrams between products.  The broad support of the XPDL standard today, with more than 60 products using it, is a sure sign that it will not die any time soon.  I only hope that this post has helped make it clear for all those die-hards out there that adoption of XPDL does not mean that BPEL is on the decline nor does the adoption of BPEL cause the demise of XPDL.  They are simply different things, like apples and oranges.