BPMN = Death to your Process?

Scott Francis
Next Post
Previous Post
Antiamba’s Ligurio says that “BPMN can bring death to your process“:
The problem lies that BPMN is so complex to implement, that people made some workarounds, simplifying process maps. If a business process needs to be mapped (some don’t like ad-hoc) it should be done in a way everybody understands it, and it can be exchanged using multiple platforms that support process notation. Once it does not happen, there is a high risk of losing process data, because you can’t use things like intermediate message, or timer, that was represented in the process repository you need to move. Thus, you are sending your process data to oblivion (and BPEL, if used, also). If process map is an asset, imagine re-training people that work in call centrer executing business processes by the book, telling that the decision gateway changed to something different, because process maps were updated to other tool. This has an impact in the way people perform tasks and in customer perception how the company execute. If process managers don’t have this concern they are very far from process execution where everything happens.
I can definitely relate to his criticisms of the tools around BPMN.  We have a problem in our business right now.  Almost every BPM software package supports BPMN.  But what does “support” mean?  It usually means, the BPMS uses a subset of BPMN notation standard.  Anything produced would be BPMN compliant.  However, it does not mean that ALL BPMN notation is available.  Therefore, despite two tools speaking a “common language” there may not be a 1-to-1 translation of a BPMN model in one tool to a BPMN model in another tool. The definition of BPMN 2 will help.  By defining a storage format, it gives vendors a more concrete target to hit in terms of export/import.  And it will make missing BPMN icons feel more like a bug than an annoyance. But Ligurio takes the criticism to BPMN, rather than, primarily, the vendors.  Vendors have got to get their act together and embrace BPMN 2 more fully. He blames BPMN for allowing you to model things so many different ways – but in a modeling world absent BPMN, this problem is worse, not better. Earlier in his post, Ligurio criticizes Blueprint for its Visio importer being less-than-perfect.  However, keep in mind that Blueprint is importing native Visio XML.  This is not some standard BPMN XML that Blueprint is importing – because Visio doesn’t produce it, despite using a BPMN stencil.  He seems disappointed with the idea of manually choosing that one kind of gateway icon maps to a split, or a decision gateway, rather than Blueprint just guessing.  Keeping in mind that Visio can label anything a split or gateway, regardless of what it truly is, this seems to be asking a bit much.  It isn’t as if you have to choose the mapping for every occurrence of an icon – just once per type. The more accurate criticism is that Blueprint doesn’t (yet) support things like complex gateways and attached events (and pools vs. lanes).  I know the Blueprint folks are trying to avoid these “advanced” use cases, but if they want Blueprint to stay relevant as users get more advanced or import valid BPMN diagrams from other tools, they simply have to add this functionality or risk becoming irrelevant. Having said that, Ligurio’s example diagram has a sequence flow crossing pool boundaries, which looks like a no-no according to the BPMN spec (they often get over-used in tools where they are supported). He runs into similar issues with ARIS and ITP Commerce.  Bottom line: he has a 25-page process. It will clearly get mangled in import routines today, and require lots of manual work to clean up. My advice:  for now, stick with one modeling environment.  Choose one that starts with modeling and lets you seamlessly add execution details.  If you use a “modeling only” environment it should stay at a very high level to work out concepts and disagreements – not to model execution-level details. BPMN2 model portability, along with the diagram interchange format, will help these problems greatly.  But the commercial vendors have to step up their game to support a much larger subset of the BPMN specification if they want customers to consider them compliant. Meanwhile, it isn’t BPMN killing your process.  It is BPMN exposing the problems in process definition and communication that were always there – but going unnoticed.  They’re now coming to light, and vendors have an opportunity to really address these issues.

Related Posts

  • Matthew Whitcombe

    Sometimes if a kite string gets too tangled, it’s best to throw it away and start again.

    Is that BPMN… and UML? Have both become irredeemably impossible for humans to understand? I sometimes think if we gave Twitter to the OMG to ‘improve’, it would come back with a 7-dimensional architecture model and need a 2-month training course.

    Play it again Jim http://blogs.gartner.com/jim_sinur/2010/08/30/bpmn-for-business-professionals-burn-baby-burn/

    • I think the string analogy works better on a single model than it does on a whole paradigm. Ie, do you stop using string on your kites? or just that *particular* string?

      BTW, I like what you’re doing with knowledgegenes. Haven’t had time to write back yet, or to REALLY dive in deeper yet, but it is interesting. Going to share with our CEO, Lance Gibbs, and get his take on it as well. Look for blog post on the subject ;) I’d love to see a fully formed model and how it plays at that point.

      Re: Jim’s post – I think the idea of throwing out BPMN completely has been pretty thoroughly discounted.

  • Pingback: BPM Quotes of the week « Adam Deane()