How Much BPMN Do You Need... Revisited

I tuned in to Sandy Kemsley's webcast for Active Endpoints on How to Explain BPMN to Business Users today to see how this pet topic of mine is filtering out to the world. Longtime BPMS Watch readers will recall the spirited discussion I had with Michael zur Muehlen a couple years back, when he did some academic "research" that demonstrated that the BPMN elements most used were the ones carried over from traditional flowcharting. No kidding... Unfortunately that was marketed as defining "all the BPMN you need." In the end we agreed to blame the headline-writers on that. Anyway, Michael has come around, through his work with WfMC and the DODAF community, and today we are in basic agreement.

Sandy didn't really tackle the question of how much BPMN business users need. She gave a serviceable presentation on what is in the BPMN 2.0 conformance classes, subsets of BPMN elements generally aligned to descriptive modeling, analytical modeling, and executable modeling. I recommend the replay. But she missed the real motivation for these subsets in the standard, which is portability of models between tools. BPMN tools rarely support all of the shapes and symbols, and never support all of the technical detail allowed for the XML underneath each shape in the diagram. The purpose of the conformance classes was to define specific palettes that tool vendors could assert support for. Modelers could then assume a model confined to such a palette would be portable between conforming tools.

Anyway, getting back to the question of how much BPMN do you need... The composition of the Descriptive and Analytical classes in the BPMN 2.0 spec originated as aligning with the Level 1 and Level 2 core palettes of my BPMN Method and Style book and training. I tried hard to get this into the BPMN 2.0 draft, but at the time, Oracle, IBM, and SAP did not want to be in a position where their first BPMN 2.0 offering would not meet all the conformance classes, even though they all agreed that a levels-based approach made good sense for maximizing BPMN adoption. (IBM's WebSphere Business Compass, for instance, implements the Level 1/Descriptive palette.) In the Finalization Task Force phase, Robert Shapiro ultimately succeeded in getting conformance classes into the final BPMN 2.0 draft, so we all owe him a great debt of gratitude. (It was not easy, and not all of the Big 3 voted for it in the end.)

In the final BPMN 2.0 draft, Descriptive class includes two task types, user (human) and service (automated); subprocess (embedded and Call Activity); exclusive and parallel gateways; 3 start events (None, Message, and Timer) and 3 end events (None, Message, and Terminate); pools and lanes; sequence flow, message flow, and association connectors; data object and data store; text annotation, documentation (invisible in diagram), and group. That's it. It's a small fraction of all the task, gateway, and event types supported in the spec.

The "hard" parts, from a tool portability perspective - i.e., many tools do not support them today - are message flows and data store. Message flows indicate communications between a process and external entities, important for establishing the business context for a process but not needed for automated execution. Oracle BPM 11g, for instance, doesn't draw message flows. Do business people need them? I think architects and analysts need them. They identify the touchpoints between a process and customers, service providers, and other internal processes. That's why I put them in. I expected them to get stripped out, but they're still there.

In BPMN 1.x, a data object was just an "artifact", effectively a decoration of the drawing with no associated semantics or rules. That's no longer the case. In BPMN 2.0, a data object is a variable stored within a process instance; a data store is data stored outside of the instance, accessible to it but also from outside. It's a subtle distinction. I wanted data store in Descriptive because modelers often use message flow to show information passing that is actually implemented via shared data. For example, to obtain billing information a process can either request it from a customer and wait for it in a message event, or look it up from customer account data maintained outside of the process instance. The latter method uses a data store.

Do business people need to understand this distinction? Hard to say. For modeling an executable process it's obviously important. But even for basic process description, if a business user mistakenly draws a data object connected to a message flow or a directed association from another pool (neither allowed in BPMN 2.0), the tool will not be able to serialize it correctly. It will give a validation error. So I think it makes sense to put data store in Descriptive/Level 1 and then teach people how to use it correctly.

In a way, we're still back to the question Michael and I were wrestling with a couple years ago. Do you want to limit the BPMN palette to what business users already know (or think they know) from traditional flowcharting, and allow them to bend the semantics and rules? Or do you want to raise the bar and say here is a common process language that can be shared between business and IT? That takes a bit of education or training, since they probably don't already know how to use it properly. But it's not rocket science.

Obviously, I favor the latter. Sandy comes out for the former, or maybe in the middle. She says the Descriptive palette is probably too complicated for business users and companies should define their own subset of it that business users will employ. Anyway, the debate is still unresolved.