In a word, no.  But ebizQ is trying to stir the pot.  What should be in it?  As expected, the dead-enders were loudest: Get rid of it altogether!  Scott Francis has more patience for this sort of thing, and has a good summary of the thread.

One of the more interesting suggestions was to split conformance requirements between the graphical notation and XML serialization.  I think that is a good idea with real practical benefits for both end users and tool vendors, but not likely to sway anyone at OMG.  In OMG, the only thing that counts is the metamodel, UML diagrams defining relationships among BPMN’s various information elements, and to a certain extent their XML serialization.  The Process Modeling Conformance subclasses in BPMN 2.0 are defined in terms of XML rather than shapes, so any graphics-based conformance would be a significant change.  OMG, I believe, would have little institutional interest in doing something like this, but its members might benefit from it.  Companies like IBM and Oracle, after exercising such a firm grip in the writing of BPMN 2.0, probably could pass a test of graphical conformance today even though they still do not conform to the XML serialization, two and a half years after the spec was finalized.

Before BPMN 3.0 comes out, there are still hundreds of bugs in BPMN 2.0 to clean up, many of them dating from the drafting period in 2008-2009.  There is a Revision Task Force chartered to work on these in BPMN 2.1, but it is dormant.  Whatever urgency there was in creating BPMN 2.0 (the failure of BPEL in the BPM market, clearly) is missing in the RTF effort.

In addition to fixing basic bugs, there are fundamental problems with the BPMN 2.0 spec narrative:

  • BPMN 2.0 assigns very specific meanings to its most fundamental concepts, like activity and process, but does not discuss those meanings in the text.  That is unfortunate because BPM architecture uses those same terms to mean very different things.
  • There is no appendix enumerating the rules of BPMN.  There are actually 4 distinct sources of truth in the spec: the metamodel UML, the XML schema (nominally equivalent to the UML but not quite), the tables in the text, and the text narrative.  They are supposed to agree but in many cases they do not, the text and tables implicitly overriding the UML (but unfortunately, you can’t override the XSD and still have ordinary XML tools make use of it).
  • The spec heavily overweights (probably by 10:1) executable BPMN over its much more common use, non-executable, yet ignores the fact that almost all BPMN 2.0-based engines today are based on Java data representations not XML.  There is no standard way to reference Java data in the serialization that preserves the transparency that BPMN was supposed to provide.

These are all “cleanup” issues.  Again, they demand a BPMN 2.1 not a BPMN 3.0, and I doubt we’ll see action there soon.

I am a little more optimistic on the model interchange front, which is trying to move forward in a quiet side effort.

Vendors are definitely but slowly moving to implement parts of BPMN 2.0.  Many are probably happy there is no good measure of conformance.  Given that pace, BPMN 3.0 would have to be motivated by fundamentally new BPM semantic requirements.  There was an opportunity to do that with ACM, but the forces wanting something completely new and different were stronger than those wanting continuity and enlargement of BPMN.  There are analogous issues in how processes deal with event streams (mediated by correlation and rules), as BPMN 2.0’s event model is too crude to represent the way software is beginning to work.  But again, I suspect that as the need grows to embrace that in a standard, it will be in terms of something completely new, not BPMN 3.0.

So love it or hate it, I think BPMN 2.0, with all its blemishes, is going to be with us for a while.