EbizQ had to ask the question: "Should there be a BPMN 3.0 and, if so, what additions should it include?"
One point of view was that the spec needed to be split into 4 specs, with more targeted purposes and test suites.? This sounds a bit like the mess that happened with the web services spec back in the mid-2000's... It went from a spec almost universally adopted spec to something that no one could make sense of and certainly no one could figure out what products were compliant. I'd rather see four testing subsets than four specs.
David Chassels' response was "No" based on the increase in complexity (partly based on Mark's comment above), but then follows up with "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!"? Ah yes. The Declarative golden goose.? Because declarative systems are so easy to use?? Prolog? Lisp?? I don't get the code generation argument because BPMN solutions done right involve no code generation nor compilation.? I think many of the people who don't like BPMN just aren't using the right tools.
Of course a few people chimed in deriding standards in general - hard to blame them - the standards-making process is painful at best.
Finally, Scott Menter (who I often agree with on ebizQ discussions!) argues that:
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.
I had to chime in with my own comment after reading all of the above:
- BPMN is not a bust. It has been massive success in terms of getting adopted compared to what came before (BPEL anyone?). It's fairly ubiquitous in BPM offerings, and therefore not differentiating (for the most part). After all that's the point of a standard!? Customers want business processes - a great BPMN implementation is part of delivering that to the Customer - but it is table stakes.
- Customers don't care about HTML either. Is HTML a failure? Of course not - it is just ubiquitous in browsers and mobile devices. Clients want the Web.? Good implementations of HTML5 give customers "the web".
- 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
Daniele Chenal chimes in to say:
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.)
Yeah, I wonder that too.? For something that is dead, it still seems to have a lot of currency for BPM and related process management techniques, with both customers and practitioners.? However, it is increasingly just expected, not differentiated.
Returning to point 3 (are there important features that require a new version of the spec?), 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 ;)
So do we need a BPMN 3.0?? Well, first someone needs to clearly propose the high value changes that would require a new version.? I haven't seen that high-value proposition yet.? I've seen suggestions, but nothing that makes me think it makes sense to open Pandora's Box.