Cool things you can do with BPMN diagrams (part 1)

One of my favorite parts of process modeling trainings is discussing with participants how do they plan to use those skills. It is a matter of process maturity in an organization (since some of the scenarios require some BPM know-how), specific goals and planned initiatives of the organizations (if you have a budget for process improvement probably you should try to make this project a success instead of adding several other elements to the scope), but also being aware of what is possible.

The goal of this post series is to give you some ideas of how process models (especially BPMN Business Process Diagrams) can be used.
Keep reading →

Back to school 2021 – free online courses for BPM professionals (and not only)

Do you want to sharpen your BPM skills and learn something new? This post is for you!

Below you can find list of free courses and trainings based on past editions of this post (in case you are curious here are the links: 2020, 2019, 2018, 2017, 2016, and 2015).

Let’s start with the gold standard of BPM courses ๐Ÿ™‚
Keep reading →

Inclusive gateways (OR) and tokens

This post is a part four of the series about token and process flows in BPMN.
So far, we covered the simple flow (part 1), situations where only one of the alternative paths could be selected (part 2), as well as cases when all paths outgoing from a parallel gateway need to complete before the process can continue after the merge (part 3). Now, it’s time to tackle more sophisticated situations.

Inclusive gateways

Inclusive gateways (commonly called OR) can be used to show that certain paths will always happen and others only sometimes – depending on certain conditions. You could say that OR gateway behaves like a (compact) mix of XOR and AND gateways.

It’s easy to recognize the OR gateways since they are diamonds with a circle inside (you can think that this marker is a slightly distorted “O”).

Let’s start by comparing OR gateway with XOR.

For XOR gateway you could have many paths outgoing from the gateway. The same applies to OR gateway – there can be 2, 3, or more paths.

Now, let’s take a look at the conditions on the outgoing paths.

For XOR gateway token would take a first path with a condition which is true. So while in practice we would expect the conditions to be mutually exclusive, in theory it could happen that two of them are true at the same time. However, XOR sends a token to a first path which has a true condition, so only one of the paths can be selected.

For OR gateway situation is different. Conditions of all paths are checked and each path which has a true condition gets a token. That’s why we will normally use a pair of OR gateways – for splitting and merging – just like for AND gateways.

Please take a look at the image below and compare differences between XOR and OR gateways.


How would your process log look like if we would have a hot (but not sunny) weather? For both types of gateways the result would be the same: ABEF.

To make it easier to remember let’s assume that it is a process of preparations for a walk and that task B is “Take a bottle of water”.

What about sunny, but not hot weather? Again, both are identical and we get ACEF. Task C could be “Take a sunscreen”.

And weather neither hot nor sunny will give us ADEF in both options. Task D could be “Take a hoodie”.

All those examples have only one token in a process instance, so we do not need any synchronization.

But if our weather is hot and sunny at the same time we will have a different situation.

Our XOR gateway cannot handle it well and (assuming the top path is checked first) we will have ABEF, so the same option as for the hot, but not sunny days. In other words, we will take a bottle of water, but not a sunscreen. Ouch! We might get a sunburn.

Luckily OR gateway comes to the rescue, and we will have ABCEF, which means we will not leave home without a bottle of water and sunscreen. Therefore we will be safe both from sunburn and dehydration ๐Ÿ˜‰

Now, let’s see how do AND and OR gateways compare. As we already discussed, OR gateways allow you to duplicate tokens, just like AND gateways. However, they allow you to send tokens only to selected paths and have a smarter synchronization.

Why smarter? Merging AND gateway waits for tokens from all incoming flows, while merging OR knows which paths were active. So we can easily leave home without hoodie if it is hot ๐Ÿ™‚

Last interesting feature of OR gateways which is similar to AND gateways is that you can have paths without a condition. Since they are always valid, they will also always get a token.

Please take a look at the animation below (taken from my course):

If you are worried that readers of your diagrams may not know it, you can always call those paths “always” ๐Ÿ™‚

On the other hand – if you are feeling geeky and names of paths like “Neither hot nor sunny” don’t sound technical enough for something which basically reminds you ELSE clause from programming you can mark such path as a “Default Sequence Flow”. It will get a nice slash at the beginning.

Please note that “default” does not mean it is most probable, expected, most profitable etc. path. It only means that token will take this path if no other path has a valid condition.

I hope you enjoyed this quick overview of most common gateways in BPMN. Stay tuned for a new post – this time about Tasks.

PS. If you are curious – there are more gateways in BPMN, but the ones we covered so far should be sufficient for the most of you.

Parallel gateways (AND) and tokens

This is a third part of the series about tokens in BPMN. The first part was about basics and simple flow, the second one was about exclusive gateways (XOR). This time we will cover cases when our process has parallel paths.

Parallel gateways

Parallel gateways (commonly named AND) allow you to show that there are certain things in your process that need to happen, but they do not need to be performed sequentially. Like every gateway, it has a diamond shape, but with a + marker inside.

They can be performed at the same time e.g. by different people or some skilled multitasker ๐Ÿ˜‰ but this is not required.

Important thing is that Parallel gateway will “copy” an incoming token, so that every outgoing Sequence Flow gets one. Those tokens flow independently through your process, so usually we need a second Parallel gateway to combine them again into a single token. This is called synchronization.

Why do we need synchronizations? There are several reasons. Technical reason: if you do not synchronize tokens, they will continue flowing and activating subsequent Activities. Business reason: usually we need AND gateways to show that some things need to be done before something else can happen.

Let’s imagine a simple process of preparing a report. After an initial analysis of a request we need some input from 3 teams: finance, marketing, and sales. It does not matter who sends us input first: finance, marketing, or sales. We need them all. After we have those 3 elements we can prepare a final report and send it.

Does it make sense to make a report on a basis of data from sales only? Probably not. Would the recipients be happy if we would be sending them 3 separate reports instead of one consolidated document? Unlikely. That’s why in 99% of cases AND gateways are used in pairs: one for splitting and one for synchronizing paths.

In case you are wondering what happens in this 1% when there is no synchronizing AND gateway: tokens flow independently, possibly causing some tasks to happen few times (so in an example above we could have a log ABEFCEFDEF). Only after the last token reaches end event process instance ends (unless you use terminate end event of course).

Since every path will get a token (we do not check conditions as we did in XOR) usually it does not make sense to add names to AND gateways.

Now, you may be wondering – would it be possible to have some paths which always happen and others which happen when certain conditions are true? Spoiler alert: you can do it with Inclusive gateways (OR), which we will cover in part 4.

BPMN vs Data Flow Diagrams (DFD)

Recently I was asked to provide a brief comparison between Data Flow Diagrams (DFDs) and BPMN and I thought it could be also useful for other people who are wondering which one to use.

As you probably noticed from other posts I work with BPMN a lot and had a chance to see many areas where it can be helpful, while I rarely see DFDs being currently used (of course except education).

Both BPMN and DFD are mature notations. DFD notation was created in the 1970s and popularized by few legends of software engineering including Edward Yourdon and Tom DeMarco. BPMN 1.0 was published in 2004, while current version 2.0 has slightly over 10 years (counting from beta release). While BPMN is still being extended and improved (e.g. by BPMN MIWG), I am not aware of any ongoing activities regarding DFD notation.

There are some differences regarding goals of those notations. BPMN charter (taken from BPMN.org) is as follows: โ€œA standard Business Process Model and Notation (BPMN) will provide businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner. Furthermore, the graphical notation will facilitate the understanding of the performance collaborations and business transactions between the organizations. This will ensure that businesses will understand themselves and participants in their business and will enable organizations to adjust to new internal and B2B business circumstances quickly.โ€

For DFD focus is different. As the name suggests data flows are of utmost importance. BABOK v3 states the purpose of DFD in a following way: โ€œData flow diagrams show where data comes from, which activities process the data, and if the output results are stored or utilized by another activity or external entity.โ€ Itโ€™s interesting to compare it to Yourdonโ€™s statements from โ€œJust Enough Structured Analysisโ€: โ€œThis is important to keep in mind: DFDs cannot only be used to model information-processing systems, but also as a way of modeling whole organizations, that is, as a tool for business planning and strategic planning.โ€

Both notations have strong theoretical background meaning they are not just pretty pictures. DFDs are based on a graph theory. BPMN can also be analyzed using formal methods.

As for the symbols, situation is more interesting. BPMN is a standard, so you can easily see which icons should be used for which object types. However, for DFD notation there are several variations, so icons proposed by Yourdon and DeMarco differ from those proposed by Gane and Sarson. Needless to say โ€“ while you can easily interchange BPMN diagrams between various tools it is not the case for DFD since there is no standard interchange mechanism.

An additional difference relating to symbols is their availability. In DFDs you have 4 elements (Process, Flow, Store, and Terminator/External entity). In BPMN you have many more symbols. On the one hand, it means that DFDs may be easier to read (especially by people with no training). However, on the other hand, it also means that BPMN allows you to show more aspects in your diagrams (e.g. process flow versus data flow).