Products

Home / Support for EA Modelling With eaTeamWorks / Insights / Creating useful, long-lasting process models

Creating useful, long-lasting process models

Process models are hard to maintain. Maybe that's because they have poor structure. Here are some ways to give them a longer life, and so make them more useful to your business.

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.

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

So you go to talk to your stakeholder, and they draw out this.

Really simple.

Something happens, then a couple of things get done, then we’re finished. And let’s assume that there is lots more to say in detail that is not shown here.

So what’s the best style to use for modelling this?

Style 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.

Management consultants seem especially fond of process hierarchies – they speak of ‘Level 3’ and ‘Level 4’ processes, as if these levels have standard definitions. Maybe they do..

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.

Style 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.
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-structured 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 the 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

Not everything which happens in a business does so because it’s part of a business process.
We call this 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 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….

Style 3 - Processes linked by events

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.

Conclusion

This process style seems to fit most of the organisations which we have worked with.

There ARE processes, and where they exist, they are important. They describe how things get done, who needs to be involved, and provide a way to measure the effectiveness of the business. But to pretend that this can describe everything that a business does is just plain wrong.

So try modelling your processes this way.

Look for the events, even if they aren’t neat, software based events but are emails or phone calls from one part of the business to another. Just understanding these events can give really useful insights into the real dynamics of a business. And you also discover some textbook processes which happen as a result of the events, even better.

More Insights

The eaTeamWorks product philosophy

22 November 2023

The eaTeamWorks product philosophy is simple - and it's all about you, the modeler.

Learn More

The role of diagrams in Enterprise Architect

20 November 2023

Not every modeling problem can be solved with a diagram. Some diagrams are essential, some are useful, but some may be misleading. But which ones?

Learn More

Explaining modelling

22 June 2023

..or, "how to reduce 20 years of modelling into 5 bullets". If you need to explain to someone what we do, try this short explanation.

Learn More

Where to start modelling

22 June 2023

Faced with an empty model and a problem to solve, where should you start? Some advice for people with no modelling experience

Learn More

eaTeamWorks Launch: What does this change mean for me?

15 June 2023

Information for existing eaDocX, Model Expert and Portfolio Manager license holders

Learn More

Create useful models using Sparx EA

1 June 2023

Advice for the new modeller #3 - Producing useful outputs with your new EA tool.

Learn More

What needs to be included in your EA model content?

1 June 2023

Advice for the new modeller #4 – (not) Modelling The World

Learn More

Beginners guide to Enterprise Architect software

1 June 2023

Our advice for new EA modellers

Learn More

How much domain modelling is enough?

1 June 2023

Advice for the new modeller #2 – (not) Melting the Pan

Learn More

Simplifying ideas in a BPMN Process Diagram

1 June 2023

How to find the right number of ideas to include in your model.

Learn More

Beck’s Map: an EA model abstraction example

1 June 2023

Possibly the best model abstraction in the world

Learn More

Process based model styles

1 June 2023

How to use BPMN and UML to make models which last.

Learn More

Where to start with Enterprise Architect data modeling

1 June 2023

BPM Tips: Advice for the new modeler #1

Learn More

Reading diagrams

1 June 2023

Why some diagrams are better than others, how to present diagrams, and how big or small to make them

Learn More

Putting EA at the heart of your business

1 June 2023

Ian's workshop at the EA Global Summit on September 14th 2022

Learn More

Compare licence prices

Choose the licence that’s right for you and your team

Prices

Download a free trial

Download eaTeamWorks today for several free for life features, plus no obligation, 30-day trials of all the products: eaDocX, ea Revision Manager, eaSheets, Model Expert and PortfolioManager. Discover for yourself why we sell the world’s best-selling Enterprise Architect extension.

Download