Simplifying ideas in a BPMN Process Diagram

A common theme to the examples in the Reading Diagrams article was that great diagrams have a small numbers of abstractions. Indeed, they are made great often by what bits of the real-world they choose to miss-out.

I’m going to refer to these not as ‘abstractions’ – it makes them sound, well, abstract, but as “Ideas”, because then I get to define what I mean.

Diagram Overloading

Consider a really simple UML Use Case diagram:

But now we’ve got started, we can tell ourselves that we need to create a one-stop diagram, which will really help people to understand these Use Cases in their wider context. So we add some more stuff:

Idea-heavy Modeling Languages

The example above is an easy one to fix, because we took the UML-defined idea of a Use case diagram, and added our own bits to it. So we can just as easily remove those bits to get back to a 1-idea diagram.

But what if the language we are using is idea-heavy? A modelling language which fits this description is BPMN.

This is a OMG way of describing business processes, and it’s an accurate way of saying almost all we need to say about processes. But that accuracy comes at a price. Lots of ideas.

Here’s a typical BPMN process.

And this is a really simple diagram. We have not said what types of Activities they are – BPMN has 8 types. Nor have we specified the data objects which are passed between the Activities, and this is a really useful aspect of BPMN.

So the very richness of the language creates its own challenges for the modeler: how to keep the number of ideas as small as possible to help the reader.

Something else which I first saw in the BPMN notation was the idea of adding lots of types to ideas, and making that part of the visual representation. For example, BPMN has 8 types of Activity: