IT-eye

Probably, most people have by now at least heard of BPMN, the Business Process Modeling Notation standard from OMG that is supposed to be the process-modeling standard. I’ve been following news for the last 2 years or so but, admittedly, never really dug deep until I started using it at a client. Even then, it was mostly sales-pitch level and learning a bit of the notation from cheat sheets like the BPMN poster. The past few months, however, I have learned more about the standard – what its possibilities and semantics are and how it can be used. I’ve had training from both a more technical perspective (in an Oracle partner training) as well as from a purely modeling-oriented training (by one of the contributors to the BPMN 2.0 specification, Bruce Silver). And I must say, digging deeper has made me quite enthusiastic about the standard!

Even now, in BPMN 1.1, the clarity of modeling in BPMN as compared to the clarity of, for example, activity diagrams is stunning. Especially the addition of several types of events, both throwing and catching, and the definition of gateways and other methods to handle these events allows an extremely precise process model. Just as a quick – and very simple – example, consider the process of handling a customer’s RFP. After receiving the RFP, you send a proposal, then wait 5 days for a reply before cancelling or closing the deal. Ignore the fact that this is bad salesmanship, please, that’s not what I’m being paid for

In a basic UML-activity diagram you would model this as follows:

Seems clear enough to you? Perhaps. Now consider the BPMN diagram of this exact same scenario:

The gateway being used here is the ‘Exclusive Event gateway’ which should basically be read as ‘whichever of the following events occurs first, follow that path and ignore all others’. Notice that not only does the gateway give more detail in (structured and validatable) symbols instead of (unstructured and unvalidatable) text, the diagram also presents more information that could not be given in the other diagram, such as the message flow and the start and end points. At least, not without adding undefined, unstandardized notation. Everything used in the BPMN diagram above, up to the type of arrows and whether or not an event symbol is solid (‘filled’) or blank (‘empty’) is defined in the notation. No more ambiguity!

The drawback here is that, for this to work, you have to have at least a basic knowledge of BPMN – such as what an event gateway is. Still, if you’re looking to standardize process modeling, look into it. It’s worth the time and effort, especially once you learn some basic ‘patterns’ that are common in process models, such as error handling, error throwing & catching and the pattern used in the above diagram, the time-out event. It certainly got me enthusiastic!