Home / Support for EA Modelling With eaTeamWorks / Insights / Simplifying ideas in a BPMN Process Diagram

Simplifying ideas in a BPMN Process Diagram

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

A common theme to the examples in the Reading Diagrams article was that great diagrams have a small numbers of abstractions. Indeed, they are made great often by what bits of the real-world they choose to miss-out.

I’m going to refer to these not as ‘abstractions’ – it makes them sound, well, abstract, but as “Ideas”, because then I get to define what I mean.

Diagram Overloading

Consider a really simple UML Use Case diagram:

It has a small number of ideas:

There are Actors and Use Cases, and Actors can use Use Cases. I make this a single idea, because it includes notions of what an Actor and a Use case are, and what the link between them means.

There’s a second idea, buts its such a small and simple one, that I don’t think this is a 2-idea diagram. The Use Cases are contained inside a box, which represents the software system we’re thinking about. So maybe this is a 1.5 idea model.

But there’s more we want to say in our modeling work.

We’ve decided to store the Issues which exist for our project in the model as well. That way, they can be linked-up to the relevant Use Cases or Actors.
Which is fine, until we add them to the diagram:

The diagram is now definitely > 2 ideas.

But now we’ve got started, we can tell ourselves that we need to create a one-stop diagram, which will really help people to understand these Use Cases in their wider context. So we add some more stuff:

We can add information about which stakeholders represent which actors, and which people in the project team ‘own’ which of the issues.

We’re now well over the line in to a 4 or 5-idea model.

Sure, it’s a one-stop diagram, but we’re asking a lot of our readers here.

Perhaps we might keep this as a diagram just for private use, and instead create several smaller diagrams which have a smaller number of ideas:

  • The original diagram: Use Case & Actors and the system boundary
  • One which shows who represents which actors
  • One showing the Issues, and their related model ‘thing’ and who owns them:

With this diagram, our layout is totally different.

We are focused on a single idea: the Issue. Issues are owned by people, and they relate to some aspect of the main model. So this is still a 1-idea model.

Idea-heavy Modeling Languages

The example above is an easy one to fix, because we took the UML-defined idea of a Use case diagram, and added our own bits to it. So we can just as easily remove those bits to get back to a 1-idea diagram.

But what if the language we are using is idea-heavy? A modelling language which fits this description is BPMN.

This is a OMG way of describing business processes, and it’s an accurate way of saying almost all we need to say about processes. But that accuracy comes at a price. Lots of ideas.

Here’s a typical BPMN process.

What we’re trying to says is:

  1. The order processing department (Lane) Process Orders (Activity), when they Receive an order (event).
  2. The QA department (Lane) then check the order (Activity) and if its ok (Decision) then the order is complete (End type Event)
  3. If its not OK, then they send an order rejection (‘send’ type Activity) to the Customer (Black Box Pool) via a Message (Message connector) and throw a Bad Order Created event (‘error’ type End Event)

And this is a really simple diagram. We have not said what types of Activities they are – BPMN has 8 types. Nor have we specified the data objects which are passed between the Activities, and this is a really useful aspect of BPMN.

So the very richness of the language creates its own challenges for the modeler: how to keep the number of ideas as small as possible to help the reader.

Something else which I first saw in the BPMN notation was the idea of adding lots of types to ideas, and making that part of the visual representation. For example, BPMN has 8 types of Activity:

This is the precision of BPMN at work. Each of these different types of Activity means something slightly different. ‘Send’ Activities should have a Message connector going from them, and will only go onto the next Activity once that message has been sent. So they are useful but they contribute to the basic complexity of the language, and therefore to the number of ideas which appear in any given diagram.

As a rule, I tend to avoid using ANY of these types on ANY diagram: I’d much rather use a note linked to a ‘normal’ (BPMN “abstract”) Activity:

I’m making a deliberate decision here to exchange accuracy for readability. The readers of my process diagrams might not know that the little hand in the top-left of an Activity box means ‘Manual Activity’, but the little note makes it obvious.

(first published on the “Artful Modeler” blog in 2015.)

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

Creating useful, long-lasting process models

22 June 2023

Process models are hard to maintain. Maybe that's because they have poor structure. Here are some ways to give them a longer life.

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

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


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.