Should there be a BPMN 3.0 and, if so, what additions should it include?

BPMN as well we all know is a highly emotive subject :-) but rather than get into the should we shouldn't we, I would like to see any BPMN 3.0 split the "standard" apart.

Too many people use the words BPMN and standard together, for some they mean notation and import/export in full, while others mean some small subset of the notation without import/export etc etc. So it is hardly a standard with so many variables, so instead of adding more to something that many see as already complex, how about we break it into subsets and have something like the following:

1. BPMN Notation - standard business subset
2. BPMN Notation - standard IT subset
3. BPMN XML - standard import/export business subset
4. BPMN XML - standard import/export IT subset

In each case the OMG should have a defined set of test cases that tools have to pass before they can say they are "BPMN compliant" - such testing will aid users and avoid much of the negative press caused by one persons BPMN being different from another and make it easier for tools to genuinely read and write to each other - for now there is still too much we import from tool XXX, but ignore the bits we don't support! hardly what one expects if using a standard.

Another approach might be to specify different subsets based on whether you are working with conceptual, logical or physical models.

I am not aiming to provide a full solution in a post, but hoping to steer some debate back on how to actually use the word standard in the right context. Overall BPMN has moved so far away from its original principles, it might be time to get back to basics (before someone just decides to completely merge it with UML :-)

I think Mark justifies my answer NO with such complexity in hands of technical people. Confine this old tech to history. There are much better ways that business can readily understand "OMDE" (Object Model Driven Engineering) where coding removed recognising business logic never changes. Declarative techniques that removes code generation and compiling delivering adaptive solutions. But no doubt many vested interests will see BPMN continue for a bit yet!

Two words: "herding cats." Standards are more about a vendor or some governing body or organization somewhere making money than helping people. Think WSCI versus BPEL circa 2003.

Whatever's added will come from a handful of the largest vendors, if not just a couple or three.

Cheers, Pat.

Per Pat's comment, I've long been known to say "he who sells the most, sets the standard"! That cynicism aside, I like Mark's notion of separating the notation from the import/export -- especially if we can heed David's call for simplicity!

Listen to me: unusually agreeable, wouldn't you say? Sorry about that ... :-)

Let's face it: BPMN is a bust. There is near-zero customer demand for it, and most of the real innovation in BPM today (such as the re-integration of time as a key process driver*) bypasses BPMN entirely.

Some standards are critical to the adoption and growth of the technology they describe: think DNS, SMTP, Bluetooth. Other standards are quickly obsoleted by the very systems they are meant to support. I think we all know which category BPMN falls into.

*) Shameless plug: Here's a white paper [PDF] I put together on time in BPM.

Great idea Mark! That would certainly add some desperately needed clarity.

Agree with many other comments as well.

To ponder this a bit further, two things I find curious. I still see clients looking at BPMS that want BPMN support. Not as much for notation sake perhaps as much for portability but that seems to be the aspect of BPMN that vendors have been least able to achieve and are unlikely to anytime soon.

The other observation is that while I have heard more than once that BPMN is dead, I wonder why it is still a highly desirable subject (based on web search stats, You tube video statistics and other data points.)

1. BPMN is not a bust. It has been massive success in terms of getting adopted compared to what came before. Its fairly ubiquitous in BPM offerings, and therefore not differentiating (for the most part). After all that's the point of a standard!
2. Customers don't care about HTML either. Is HTML a failure?
3. Before we ask whether there should be a BPMN 3.0, we should ask if there are IMPORTANT features to add to BPMN that require an update to BPMN 2.0

To my last point there, what I'm getting at is first someone needs to articulate a solid value proposition for adding something to the spec. If there are enough new ideas that have enough net-new value, then we should pursue a 2.1 or a 3.0 release.

If the new ideas don't have enough value, then we should stick with what we have. If the value is clear, then we should think about pulling together an effort to refine the spec.

I think too often people are focused on iterating the spec, regardless of the value. I think we can all come up with a few examples of this in standards that are near and dear to our hearts ;)

Very interesting dialog...lets see the outcome of the BPMN MIWG (BPMN Model Interchange Working Group) that has mandates to facilitate, resolve, identify and establish some of the very points in this thread.

http://www.omgwiki.org/bpmn-miwg/doku.php?id=start

@ Pat +1

Bl**dy Pointless Monetized Notation

The issue with BPMN is that for the most part it's a guide and only those with a massive investment in BPMS will stick to it rigidly, otherwise people will just chop and change it as they see fit in accordance to their need.

In a world where everything is moving so rapidly and leaner startups are creating solutions that are beginning to outstrip legacy vendors this is a lumbering dinosaur that needs to fall into a tar pit and sink to the depths. The only new workflow tools being designed with BPMN in mind are the ones who are foolish enough to enter such a crowded market, who needs another drawing tool, the intelligent ones are creating solutions with no regard of BPM history and frankly are looking better for it.

You're talking about creating v3.0 when you haven't even bothered to finish v2.0 yet.

+1 Scott

Here is the Manifesto for BPMN 3.0 that I ublished last year: http://vishals.blogspot.com/2012/10/manifesto-for-bpmn-30.html

@Theo - I agree with the fact that solution based startups like Asana and do are stripping the legacy vendors. However the work on the underpinning of process models or process graphs is not lost. It would be equivalent to suggesting that because we had Spring framework, JSPs ceased to exist - and we both know it isnt true.