Wish List Revisit Revisited

Last fall I wrote a column and subsequent blog post called My BPMN Wish List, discussing some useful semantic patterns that were hard to diagram in BPMN. I didn’t get much comment on it, so I was a bit surprised to find recently on the OMG site a featured white paper by Antoine Lonjon, better known as the author of the BPDM spec, entitled The BPMN Wish List Revisited. It might seem flattering that my wish list turned into the wish list, but the opener dissed that idea:

In recent articles, people have expressed some desires and concerns regarding BPMN. Some of them are actually already addressed by the latest version of the specification, while others could be reformulated for consistency.

Ouch.  No mention of my column, blog, or name even, and I didn’t even know about it until I stumbled upon it, but I think it’s worth revisiting Antoine’s revisitation because it points out where I think BPDM is going wrong.

One of my wish list items was called Multiple Start.  It’s where you have multiple entry points to a process, typically (although not necessarily) based on the channel of request.  For example, a customer service request could come via the call center, email, or the web.  Downstream the process is the same, but the initial steps are frequently channel-dependent.  This is a fairly common scenario.

What I didn’t realize last fall was that BPMN 1.1 solves this use case explicitly, using event gateway to “bootstrap” the process.  Like this:

That’s cool.  Not especially consistent with how intermediate events work normally (they normally wait for events), but who cares?  So what Antoine should have said is, hey Bruce, read the spec.  It’s in there, now.  But instead he said that since the channel of contact is external to the process, the channel-specific initial activities should be in separate pools.  Here’s Antoine’s corrected solution:

Now that’s just silly.  There are reasons to use multiple pools in a process, but since they add complexity the reason should be a good one, and this one is not.  Here’s a situation where the BPMN spec added a new diagram pattern to solve this common use case, and the author of BPDM – supposedly the formalization of BPMN – says it’s unnecessary.  Does that make sense to you? 

OK, next wish, the nonaborting unsolicited event.  This comes up all the time.  An intermediate event attached to an activity, such as message or timer, aborts the activity if event trigger occurs while the activity is running, and redirects processing to the exception flow out of the event.  Extremely handy construct, since the activity can be a subprocess inserted for the express purpose of defining the scope of the event.  But in addition to the aborting event, wouldn’t it be nice to have similar scoping behavior but allow the event signal to trigger an exception flow without aborting the activity?  Of course, it’s another real-world processing pattern that deserves a place on the wish list.  I described how to do it in a workaround, and subsequently I have developed a better more general one. 

For example, consider event E attached to activity A.  If E occurs while A is running, A is aborted and the exception flow is executed.  The non-aborting variant is this: if E occurs while A is running, A (and the normal flow subsequent) continues, but a parallel exception process is triggered.  How do you model it?  Here it is:

You need to wrap A in a subprocess, with a parallel path containing E as a “wait-for” message event.  If E occurs, a message end event triggers the exception process in a separate pool.  (There are special cases, such as simply issuing a reminder, where you don’t need the complication of a separate pool, but the general case is more easily modeled this way.)  The end event following A inside the subprocess is a Terminate event.  That means if A completes before E occurs, the path waiting for E is killed. Otherwise the subprocess could never complete.

So this works, and I teach the pattern in my BPMN training, but I call it a workaround because it adds complexity for a very common situation.  What would a non-workaround – my wish list item – look like?  It would be some graphical variant of the attached event that the BPMN spec says means non-aborting.  For example, the double circle for the event might be dashed instead of solid.  Or, if you don’t want to add a new shape to the graphics library, borrow the start event (single circle) shape for E attached to A. I don’t care what shape they decide on, as long as the spec says this shape used in this way means non-aborting scoped event.

But again, Antoine is having none of it.  And what he says is kind of shocking, which is that the non-aborting attached event “is already supported in the OMG BPM specification.”  Really?  And what is “the OMG BPM specification”?  Is that a typo?  Does he mean BPMN specification or BPDM specification?  And is there a difference?  He goes on:

The good thing with the OMG BPMN specification is that new kinds of behavior can be defined for this ?attached to the boundary? relationship. An example of new behavior can be exactly the one described

[i.e. non-aborting]…. This is made possible because the OMG BPMN specification is underpinned with a consistent and extensible ?behavior model? that defines the rules for starting, ending, aborting, etc. The default behaviors are the ones most commonly used by process modelers….  Therefore, process modelers don?t even have to think about them. But whenever required, this behavior model can be accessed and even extended.

Now we get to the heart of the matter.  This is a serviceable description of OMG’s metamodel initiative, BPDM, which is not out yet.  But that’s not BPMN.  The metamodel has the goal of formalizing behaviors and tying them back to the Meta Object Facility (MOF) so that modelers can define their own behaviors, serialize that model in XML, and the code generation will be (supposedly) unambiguous.  That’s not of any particular interest to me, but it seems to be something that MDA people want.  OK, no problem with that.

But I say it again, that’s not BPMN.  BPMN isn’t about user-defined behaviors.  It’s about particular shapes and symbols, drawn in the diagram in a certain relationship to other shapes and symbols, having specific semantics that are standardized and clearly expressed from the diagram itself.  At least that’s my opinion what BPMN is about.  And I think that view is consistent with the passage on extensibility in the BPMN 1.1 spec (section 7.1.3):

BPMN is intended to be extensible by modelers and modeling tools. This extensibility allows modelers to add nonstandard elements or Artifacts to satisfy a specific need, such as the unique requirements of a vertical domain. While extensible, BPMN Diagrams should still have the basic look-and-feel so that a Diagram by any modeler should be easily understood by any viewer of the Diagram. Thus the footprint of the basic flow elements (Events, activities, and Gateways) should not be altered. Nor should any new flow elements be added to a BPD, since there is no specification as to how Sequence and Message Flow will connect to any new Flow Object.

Note this doesn’t say that modelers can redefine the semantics of standard flow objects, and it does say they can’t add new ones.  The can only add other “elements or artifacts” – which cannot have sequence flows attached.  That’s why my wish list is a wish list, because it’s the BPMN 1.x or 2.0 spec that would have to add the new flow objects or new behaviors for existing ones.

Here’s my main point.  The BPDM people in OMG like to say BPMN is vague and needs a formal metamodel.  It is vague in a few places, but mostly BPMN is quite specific about the semantics of flow objects.  It is BPDM that adds countless new states and behaviors not described by BPMN.  That’s fine for BPDM, because BPDM is not really about BPMN, but is a general framework for all modeling notations and languages.  Why can’t they just come out and say that, instead of these back-door attempts to redefine BPMN. even when the BPMN spec — which just came out in January — says something different?

The real value of BPMN is that the notation – i.e. the diagram – is not only expressive but standardized.  A particular shape means a particular thing, apparent right from the diagram.  That’s one of BPMN’s essential differences from a tool like ARIS, where an arrow just signifies that a relationship exists, definable by the modeler, between the thing at the tail and the thing at the head.  In BPMN, a sequence flow means one thing and one only, so you don’t have to consult the repository (and maybe the modeler) to understand what the diagram means.  It’s obvious right from the printed page. 

My wish of all wishes is that tool vendors would all serialize BPMN the same way, so that not only would a printout of the diagram mean the same thing across tools but the XML would as well.  BPDM claims it offers that.  But how can it, when it won’t admit that BPMN is not about user-defined semantics, but about connecting spec-defined semantics to standardized shapes and symbols?