Five Things to Love About BPMN 2.0

BPMN 2.0 is almost here. If all goes as planned, it will be voted on by OMG members in June. Assuming it passes, that doesn't mean BPMN 2.0 is officially adopted and available in commercial tools, just that it has entered the "finalization" phase when tool vendors can start building it in. Even though the diagram notation of BPMN 2.0 appears little changed from previous versions, it represents a big step forward.

Most of the effort put into BPMN 2.0 has focused on making the diagrams executable on a process engine. That will be huge for customers of Oracle, IBM, SAP, and other vendors who elect to go that route. But even for the majority of today's process modelers, who are just thinking about BPMN as a diagramming tool for documenting, analyzing, and improving - not necessarily executing - their business processes, version 2.0 offers a lot to love.

Here's my pick of the top-five improvements:1. Model interchange between tools. Students in my BPMN training can hardly believe it when I tell them that moving their models from one BPMN tool to another generally means drawing it all over again. Isn't BPMN supposed to be a standard?

Well, ummm, yes, OMG has said in the past. We specified what the shapes look like and what they mean, but not an XML interchange format for the models.

That's all changed in BPMN 2.0. It provides a standard XML schema for interchanging BPMN models, both executable and non-executable. In fact, it's the same schema for both. There is just more technical detail in the executable model.

2. Non-interrupting events. The biggest difference between BPMN and traditional flowcharting has always been support for events. An event is a signal that "something happened," and BPMN lets you say how the process should respond: start a new instance, redirect to an exception path, resume a paused flow, or abort a running activity. The one event-triggered action it had no simple notation for was starting a new activity or flow within the current process, without interrupting the main thread of execution. BPMN 2.0 now provides that in "non-interrupting events."

That sounds complicated but it's usually the behavior you want. For instance, a timer event lets you specify a task deadline, but if the deadline expires you don't necessarily want to abort the task. More often you just want to send a reminder to the performer or notify the manager, while letting the task continue. Similarly, if a customer updates an order in process, you don't necessarily want to abort the order processing, just add more stuff to it. BPMN 2.0's non-interrupting events let you do just that.

3. User action. BPMN 2.0 provides a new event type called escalation. Escalation represents a signal generated inside the process. An escalation event on a User task (i.e., human task) means that while performing the task, the user might issue this event, which would trigger the actions specified in the diagram, either cancelling the user task and doing something else or initiating some other activity flow in parallel. This gives BPMN 100 times the power it had previously to model semi-structured, collaborative, and ad hoc behavior.

4. Business rule task. No other aspect of BPM is responsible for as much misinformation, disinformation, and deliberate obfuscation as the relationship between process and business rules. They are different things, but they need to work together. A major problem has always been that tools have not had a way to properly represent business rules in the process diagram. (I am not talking about routing logic embedded in gateways. Both the business rule and BPM communities, when they are on speaking terms, now agree that these are not what we mean by business rules.)

BPMN 2.0 offers a new task type that specifically indicates invocation of a business rule, or what BR-people prefer to call a decision or ruleset. It is really a special kind of automated service task. In the process model it does not take any action. It just returns the rule result, which can be used by subsequent process logic in a variety of ways. No, it's not profound, but it should hopefully put the lid on what has long been an annoying distraction.

5. Easier event implementation. I'm not going to call them out here, but a number of nominally BPMN-compliant BPM Suites support exception-triggered behavior but not the BPMN notation for it. I think that's bad because it reinforces the idea that handling exceptions is an IT coding problem and not a concern of business. The real issue is that these tools' associated process engines cannot easily implement the semantics of BPMN boundary events. In fact, this is a problem for BPEL engines.

To address this difficulty, BPMN 2.0 adds an alternative construct called an event subprocess. Event subprocesses encapsulate the exception handler in a subprocess triggered when the event occurs. This supports most of the situations where BPMN boundary events are used, but is more easily implemented by existing process engines. Thus event subprocesses effectively remove a key barrier to true BPMN compliance by the majority of tool vendors.

Most BPMN 2.0-based tools won't arrive until the end of this year, but the new improvements cannot come soon enough for me. I'll be giving a preview of them at my next two-day BPMN class (at a pharmaceutical company in April), and I will be incorporating BPMN 2.0 into the full BPMessentials training as soon as the tool we use, Process Modeler for Visio from itp commerce, supports it, hopefully in June. At that time, I am also launching my book, BPMN Method and Style. More on that topic to come...Most of the effort put into BPMN 2.0 has focused on making the diagrams executable on a process engine. That will be huge for customers of Oracle, IBM, SAP, and other vendors. But for process modelers, who use BPMN as a diagramming tool... version 2.0 offers a lot to love. Here's my pick of the top-five improvements: