I’ve been creating models and teaching modelling for quite a few years now. Domain models, use case models, state models and architecture models.
But I usually sigh when a client asks me to teach process modelling. Not because it’s especially hard to teach, though BPMN has made everything a little more complicated. It’s because, unlike all the other types of models, process models don’t seem to last very long.

I sometimes go back to customers many years after an initial engagement, and often there will be the domain model we created together. These seem to be the longest-lived, probably because they capture basic business ideas, and these don’t change much over time.
Use Case models also survive well. The systems which implement them maybe don’t turn out exactly as the use cases described, but they are usually a fairly good guide to how stuff works.
But I’ve never, in 20 years of modelling, been back to a customer who said ‘hey- that process model we built – it’s still going strong’.

Process models seem to be more disposable. Not by design though. It just seems to happen that way.
And there’s no reason why this kind of model needs to be like that. If they are created and maintained well, process models can help a business to understand where it’s adding value to its customers, where efficiencies can be made, and what role a new software system might make in improving the overall picture. And this should be fairly stable over time. Sure, businesses re-organise all the time, but the things which a business does usually change much more slowly. You may out-source a little here, combine a department there, but the same stuff will need to get done.

So the problem of making process models more useful and longer-lived seems like one worth thinking about, and which is what this article will discuss.

We’ll look at the different structures of process models: the ‘patterns’ or ‘styles’ if you like – and see how we can use those patterns to make process models easier to create, easier to read and validate, and easier to grow and maintain. These aren’t patterns in the ‘Business Process Patterns‘ sense, nor are they concerned with the detailed style of the processes [See Bruce Silver -BPMN Method and Style] They are structural patterns, which are more to do with which bits of BPMN we choose to use when creating processes.

Three Styles

So here are three styles. The first – hierarchy – which seems to be everyone’s default. The second – Calling – where smart modellers go when models start to get big, and finally ‘Event Linked‘ which I only see very occasionally, but really should get used MUCH more.

So you go to talk to your customer, and they draw out this:

Really simple. Something happens, then a couple of things happen, then we’re done.simple process

So how to model this?

1 – Hierarchy


This is maybe your first thought, assuming that you don’t just keep things as above.

You decide that one process contains the other, in a hierarchy.The top-level process has activities which decompose into lower and lower level processes – they are shown here on the same diagram, but of course each process would have its own diagram.
This shows only two levels of nesting, but 5 or even 10 levels are not uncommon.
Essentially what we have designed here is, in programming terms, a ‘main’ process which has lots and lots of sub-routine calls.

Processes built like this work fine, until they start to grow, and when we discover that processes in one hierarchy want to use ones from elsewhere. Then it looks less neat. And turf wars start to decide who ‘owns’ the common processes.

2 – Callable (re-usable) processes

A process model which uses only processes with sub-processes will clearly not create any re-usable processes. Which is probably not how many businesses work.
What we need to add to the simple hierarchy is the idea of one process calling another one.Calling
This is implemented in BPMN, even if it’s rather hard to understand. There a little magic involved in saying one process ‘calls’ another, and in setting-up the governance required to manage these re-usable processes. But at least we can easily see where the re-usable stuff is.

But if used together, the combination of Hierarchical and Callable process styles seem to suffer from explosive complexity.
Put simply, they do not grow well.
As they get larger, maintaining all the links between all the process – deciding who is a child of whom, and who calls whom – start to overwhelm many process modellers. At which point, they seem to revert to ‘modelling tool = Visio‘ mode, where the integrity of the model is lost, and instead they get a series of pictures. The pictures may look nice, but they aren’t a model, and require the ‘wetware’ of the modeller if they are to add value to the business.
What’s needed is a way of allowing models to grow elegantly:

  • Allow modellers to create well-modelled processes, with the smallest scope possible which is consistent with achieving the business objectives…
  • ..whilst still showing the interconnections between different parts of the business.
  • Challenges a false, hidden assumption which we may have missed: If I’m a Business Process Modeller, and I’m looking at stuff happening, then that stuff must be happening because it’s a process. But there might not be an end-to-end process

3 – Event based processes

Not everything which happens in a business does so because it’s part of a business process.
This is the Business Process Illusion.
Sometimes, stuff just happens. And that stuff makes other stuff happen, and it’s hard to tell where it’s all leading to, but the stuff still keeps happening anyway.
So maybe if we recognise that this is what’s really happening – some well-structured processes in a soup of ‘stuff happening’ – then we’ll spend less time trying to create processes where none exist. And we’ll also create models which better reflect how our business really work, and which are maintainable and readable.
So our business maybe looks like this:

  • stuff happensEvents happen in the outside world, over which we have no control
  • These trigger processes, which end with other (internal) business events.
  • These events in turn trigger other processes
  • ..but there is no end-to-end process: just processes creating events, which trigger processes.

So our example process can look like this:


This approach has lots of advantages for the modeller:

  1. Each process can be written in a self-contained way, with well-formed start-, end- and intermediate events (in BPMN-speak)
  2. The events which come out of processes can be understood as proper Business Events, which might have already been modelled elsewhere, such as in Archimate .
  3. Processes can be given a scope which reflects how a business works, rather than trying to pretend there is an end-to-end process where the business doesn’t really have one.


In reality, a blend of each of these approaches is probably what you need, but recognising that there are (at least) 3 different styles to choose from means we’re not constrained to simple hierarchical processes, with their giant-sized end-to-end scope.

Because we all know that sometimes, stuff happens.

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: