Process based model styles

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.

This may be because we don’t model things in a way which allows the process to evolve over time, which is what we know our organization will certainly do. But we may be able to help this by thinking about the style and scope of the processes we create. Perhaps then we can make them more long-lasting.

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.

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.

This so popular that the different levels in the process hierarchy get given names: you’ll hear consultants talk about “Level 1 Processes”, or even Level 0 (which are usually something crazy like ‘Run the Business’), so this idea of hierarchy has lots of friends.

But it’s an illusion.

There is no ‘run the business’ process: it has none of the characteristics of the process (start, end, owner, metrics)  – it’s just there to make the PowerPoints look neat.

(end of rant)

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.
• Challenge 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

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 works, and which are maintainable and readable.
So our business maybe looks like this:

• Events 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, which create….

Summary

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 just happens.