How to simplify BPMN Data Models

You’ve probably seen one of these ‘look at me’ diagrams. You may even have created one.

They are the big, colorful ones which sit over the desks of some modellers. They have loads of boxes, even more lines, and they are designed to say one thing.

Can you really look at this diagram and see where something is missing? The example above is from the OMG’s BPMN modelling language, and is one of their demonstration examples, presumably to show what a great thing BPMN is.

But it’s a hopeless way of conveying information  – which is one purpose of such a diagram – and shows lazy modelling. By lazy, I mean intellectually lazy. Not time-lazy, as it clearly took ages to create. The modeller chose not to use their knowledge and experience to chop the diagram into bits, so they they and their readers would have a chance of spotting the gaps, overlaps and inconsistencies.

Because this is what we’re supposed to be doing.

4 ways to spot you have a 'look at me' diagram

1. You’re starting to feel that printing the diagram and putting on the wall near your desk will enhance your chances of promotion
2. You’ve spent a hour on the internet looking for a device driver which will let you print it on a giant printer
3. You found the driver, but not the giant printer, but you did find lots of sticky tape and glue in the stationary cupboard, so now you’re having loads of fun joining the bits together
4. If you print the diagram as A4/Legal size, the writing is only visible with an electron microscope.

..and what to do about it

1. Chop it into pieces.

That’s it. Simple.

Well, not always.

But this where we show our modelling skills. We’re the ones who are supposed to be able to pull all this knowledge into our heads, and write down a set of smaller, easier diagrams, which help a reader to work they way into the problem. This is our job.
More on ‘how to make diagrams readable’ in future posts.

So, if you get me in to your project to see what you’ve been modelling, and you have one of these diagrams over your desk, don’t expect me to be impressed.

Update - August 2020

A while back, I had some time to spare on a long train journey, and decided to take the example above the create some more useful diagrams from it.

As I was doing the simplification, I wrote down the decisions I was making as I did it:

• Split the diagram – Make it into at least 4 different diagrams, corresponding to the main clumps on the original picture
• Add some intermediate business events – Link the new top-level processes with Business Events, to show the sense of the process.
• Make separate diagrams to show where the Data Objects fit – There are too many of these, so have one diagram where they don’t appear, so readers can get the idea, then another where we add this additional detail.
• Remove multiplicities from Black Box and Data Object – Having the multiplicity symbol on the Voting Members black box is not helpful. The clue is in the name. Members plural. Just more notation to forget.
  Also removed the multiplicity symbol form the Issues List. Apart from the fact there is only one list, not many, it’s obvious what this means. Symbolic clutter
• Give parallel flows an explicit branching gateway – It’s not clear in the original where and why the ‘Announce Issues for Discussion’ Activity causes a parallel branch. As I added one, so we can see that only after it completed does the flow branch.
  This might not be what the original modeller intended, but I think this is clearer. If it wrong, then it’s clear where to correct it.

So here is how I re-imagined this diagram.

The Sub-Processes

Simplifying things is Complicated

I probably spent a good few hours simplifying this process, but in doing so found lots of questions which I’d like to ask the authors. So that’s me doing my job of using the model to Analyze stuff .

At the end of it, I think I not only understand what they are trying to say, but I could also give someone a document which would help them to understand it too. It would have the top-level diagram, then the sub-process diagrams, and some additional diagrams with supporting details.

The process is then not just a big, clever-looking diagram which nobody understands. It’s been added to our collective knowledge. I don’t need the authors in order to understand it, nor a PhD in BPMN notation. Anyone who knows a little BPMN could understand it and even improve the process.

Job Done.

PS. If you’d like a copy of the ‘before’ and ‘after’ models (as an XMI file out of Sparx Enterprise Architect) then email me at ian at eadocx.com