(follows from the look-at-me-diagrams post)

Having railed against the ‘look at me’ diagram (see previous post), I thought it might be helpful to see what can be done about them.

If you have such a mega-diagram, then whilst it might be useful for you, it’s not going to look great when printed, especially if your readers will need sticky tape and scissors to make sense of it.

So chopping it into bits seems like the way forward. But this isn’t just a tedious bit of drag & drop to some new, smaller diagrams. It’s an opportunity to do that thing we do – model – and increase the value of that bit of our model, and add to the collective knowledge of our organisation.

So here’s an example.

It’s always good to go to the experts to get an example model, so I chose the People Who Know – the OMG. These are the people who tell us all how to model, so they should have some helpful stuff. And, as it turns out, they do. But perhaps not in the way they intended. Below is one of the examples which they publish to show what the BPMN language can do for modelling business processes:

big process model

OK, so I have inserted the diagram quite small: you can find the original, with a great explanation, at the OMG/BPMN site, but my point is that this is a large and complicated diagram; I count about 75 boxes, and, more importantly, about 10 different modelling constructs. But this is the OMG showing-off BPMN, so its not too surprising that its complicated. I’m just going to use it as an example starting point to see how mega-diagram can, and should, be broken up into smaller pieces.

An Overall Structure

This is the easy bit.Sometimes.

To make a diagram like this easy to understand, we need to ‘chunk’ it. Make it into the smaller bits. Very few mega-diagrams are uniformly complex – they mostly have natural ‘clusters’ of things, and this example shows that really well.

The two big yellow blobs (BPMN Processes) look like good candidates, as do the bottom right-hand and top right corners.

diagram with chunks2

So I decided on a few initial ‘chunks’ and made those bits which weren’t already sub-processes into their own sub-processes.

Even the act of drawing the red boxes (which are just for illustration, not part of our model) makes the model easier to understand: the reader can start to concentrate on smaller bits, and not get intimidated by the whole.

Now we can start to make progress. Having decided that there are 6 big boxes, we can put just those bits into a new diagram, and hook them up with events:

overview BPMN diagramTo create this diagram, I’ve added EVEN MORE BOXES. This is ok – making stuff simpler doesn’t mean the same as making it smaller. I’ve chosen to link my top-level processes with Business Events (see process modelling with style), but it gives a sense of purpose and achievement to the overall process:

  • stuff happens, which creates a business event (which we might expect a business person to understand),
  • ..which in turn allows further processing to take place.
  • …which results in another business event

It’s this kind of analytical thinking which is where we earn our living as modellers. Anyone can copy/paste boxes from one diagram to another. We’re adding-value and helping understanding. By the way – it took me quite a while to do this, and I kept the mega-diagram to make sure I’m not messing-up the overall picture.

The Sub-Processes

Now that we’re freed from the mega-diagram, re-organising the smaller ones isn’t so hard, but there’s still work to do.

If left un-edited, one of the boxes looked like this:

unedited Sub Process ..which I found hard to understand, so I re-structured and re-drew it to look a bit simpler:

This diagram is simpler for a number of reasons:

edited sub process 1- I have removed some of the diagram elements, namely, the notes and the Messages, to the black box pools. These appear on another, similar diagram which has all the detail.

2 – I’ve added the business events (not part of BPMN) top left and bottom right, to show how the sub-process starts and ends. This immediately suggests that I may have forgotten something: the process has no error conditions. Something to look into…

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 abilityengineering.co.uk

About the Author Ian Mitchell

Ian Mitchell is a business analyst and software developer. He's been using UML since before it was UML, and has managed teams of BAs all over the place. He also teaches UML and BPMN, and writes the eaDocX document generator for the Sparx EA tool.

One comment

%d bloggers like this: