One of the reasons for my absence from the blogosphere this month is I’ve been heads-down putting together my training on Process Modeling With BPMN. But when I talk to vendors about what I’m trying to do – teach business analysts how to use things like gateways and events correctly and with a recognizable business purpose – they kind of chuckle at my quixotic delusion. You’ll never get business analysts to understand that stuff, they say. But I’m still of the mind that the main reason business people don’t quite get BPMN yet is that the tool vendors themselves don’t follow the spec. Come on, guys, it’s not that hard.
Let’s start with the free tools. Savvion, overall a really good one, since it includes simulation analysis (and form builder and other stuff)… for free. But guys, a parallel split is the diamond with the + inside, not the one with a * inside. That means something else.
How about Tibco? This clip came from Sandy’s blog about it, so I’m not sure of the source of this diagram, but it’s not valid BPMN.
There are 2 paths coming out of the exclusive gateway (diamond with an X inside), but they’re drawn from the same point of the diamond. That’s not illegal per se, but confusing since those are alternative paths not a parallel split. The thing that’s illegal is drawing a conditional sequence flow (the little diamond on the tail of one of the sequence flows.. here you can’t even tell which one) out of a gateway. Conditional sequence flows can only come out of an activity.
OK, how about Appian? Sandy swooned over that one. And it does look pretty nice. Just a few spec violations in this diagram.
For example, see that gateway labeled XOR? Is that a decision or a merge gateway? It can’t be both, no matter how much Appian wants it to be. That timer event labeled Wait for Appointment is also used as a merge (2 sequence flows in)… can’t do that in an event. But those are technical violations, since you can probably figure out what they meant.
But what about borrowing the ad hoc subprocess symbol (~) and plopping onto a task, which I guess means “this thing may or may not happen.” Sorry, that’s not BPMN. They use it in a couple places. At the top one labeled Cancel Request, I guess it’s supposed to model the possibility of cancellation of the process in flight. But that’s not how you would do it. You should wrap the whole thing in a subprocess and use an attached message event. The other one, on the right labeled Reschedule Appointment, is probably another attached message event (in response to a reschedule request)… but I can’t tell from the diagram exactly what’s happening there.
OK, how about Intalio’s open source modeler? Admittedly this diagram, from the website hosting the download, would make a business analyst’s head spin, since it looks like using BPMN to model some low-level service invocation. But too bad it’s not even valid BPMN.
What’s wrong here? For starters there’s an attached compensation event with a sequence flow out of it going to an event. An attached compensation event can’t have sequence flow out, just an association (dotted line) to a single compensating activity. The attached timer event has a sequence flow directly to an event-based gateway (that’s the diamond with the event symbol inside, plus the 2 events hanging off of it). Not only does that make no sense semantically, it’s not legal in BPMN. Also you can’t have a “None” event in an event-based gateway, and the gateway has to go somewhere, it can’t just end the process. This diagram is just a doodle; it shouldn’t be front and center on the Eclipse website.
And last, but not least, there’s ILOG. I blogged about that one in September. Fifteen BPMN spec violations in their sample process model! That has to be some kind of record.
The wrong takeaway from this post would be that BPMN is complex, too complex for business analysts. Maybe the semantics of the Error event are tricky, but the rest of it is not rocket science. I’m saying the rules are actually pretty simple, but the tool vendors are simply inattentive in their marketing. I’m sure someone at each of those vendors knows the spec inside and out, but those aren’t the guys making the sample models and screenshots for the marketing collateral. Also, the modeling tools obviously don’t include validation routines that weed out illegal diagrams.
All of that is a shame, since the top-tier BPA tools, like IDS Scheer, ProForma, and IBM, don’t use BPMN, or at least don’t use the cool parts of it, like intermediate events. So when those guys say BPMN’s various gateways and events are too complicated for analysts, how can the BPMN tool vendors argue otherwise? It looks like they don’t get it themselves.
Excellent analysis Bruce. Your conclusions are particularly salient: BPMN is complex, but not too complex for business analysts nor should it be too complex for BPM tool vendors to properly support in their tools, particularly those who claim such support.
Nice to see you blogging again.
[…] An important downside of BPMN is that it has strict rules but no standard methodology. Each tool vendor tends to ignore the rules and assume its own methodology, based on the subset of BPMN that it implements. The BPA vendors just support a limited piece of BPMN, and the BPMS vendors? methodology emphasizes building the executable implementation, which is beyond where most people starting out in BPM want to go, at least immediately. That means that while BPMN takes a quantum leap beyond traditional process modeling, business analysts are left in the dark as to how to use it correctly and effectively. […]
Bruce,
Great job that you’re doing with this kind of blog entries… However, for the record, let me correct something that you wrote:
“…For example, see that gateway labeled XOR? Is that a decision or a merge gateway? It can?t be both, no matter how much Appian wants it to be….”
Well, I’m not sure about this, here’s a quote from page 70 of the BPMN adopted spec:
“A Gateway MAY have both multiple incoming and outgoing Sequence Flow.”
The spec is not overly clear about the meaning of gateways with multiple incoming and multiple outgoing sequence flows. But after reading pages 70-100 of the spec, I gather that such a gateway is equivalent to a composition of two gateways: a first gateway with multiple incoming flows and one outgoing flow, leading to a second gateway with one incoming and multiple outgoing flows.
I also wanted to react to your comment that vendors find it quixotic that you would seek to teach business analysts how to use things like gateways and events correctly. Well, they should start waking up to reality! We’ve been doing exactly this for already a year here in Australia, and people have been very receptive. And I’m talking about real business people, with no knowledge whatsoever of software development in any way. We even get into event-based decision gateways, and when we do so, people say, “Hey, we should use this feature in this or that process model!”
In fact, some of our customers had previously undergone other BPMN training courses where there was no mention of gateways and events. And when they saw that gateways and events existed, they quickly appreciated that they could capture so many new nuances with them. It makes them think more deeply about their processes, and that’s precisely one of the key outcomes that process modelling is meant to achieve.
It is indeed about time that vendors realise that people are looking for a bit more than boxes and arrows.
Marlon,
You got me! Yes you and Appian are correct and I am wrong about the gateway that can be both a decision and a merge. And I think I was also incorrect somewhere else where I said that an intermediate event cannot be a merge — the spec in fact does not say that, so I suppose wherever multiple uncontrolled flows into an activity would be lagal, an intermediate event in place of the activity would also be legal.
And… since I’m reading over p70 of the spec, I see something else. I say in my training it is illegal to use a gateway as the start of a process (in place of start event), but that’s apparently allowed as well.
I think all of these legal constructions are probably not best practice (if broad understanding is the goal), but legal.
Thanks for pointing out my errors.
Bruce,
I really like your blog!
Just a little detail concerning intermediate events: They can according to spec p61 neither be a merge nor a split.
Stutz,
Yes you are correct, and I guess I was also correct in my original statement, that an intermediate event cannot be a merge. In my copy of the spec (OMG 2006-02-01) it is on p.48.
Bruce, this is late, but just a word of thanks for your insightful analysis upon which i have only just stumbled. It encapsulates a great deal of the frustrations encountered in my (as yet early) learnings of business process modeling from the business analysts perspective using the BPMN. The irony of vendors claiming that non-technical analysts won’t “get” BPMN is quite laughable. I have only been dabbling with the Tibco and Intalio tools and they make me tear my hair out. I’m a little dismayed to learn from your post that the other tools don’t fare any better wrt BPMN spec compliance.
[…] Why can’t all products interpret the BPMN in the same way? This is another of Bruce’s concerns. Why can’t there be a single dialect of BPMN? Please stay tuned for my next post. […]