Sebastian Stein's picture

Computer users love to challenge each other by starting totally useless "flamewars". Just think about how emotion comes up if people discuss Windows vs. Linux, Extreme Programming vs. classical software development, iPhone vs. Android, PHP vs. Ruby or EPC vs. BPMN. Wait, EPC vs. BPMN? Yes, I noticed several times that people have very strong feelings about both process modeling notations and tend to favor one over the other. For example, both groups (EPC lovers and BPMN lovers) claim that their notation is more expressive than the other one. But how could that be? Is one group lying? Or is there just a big misunderstanding?

In this post, I like to give a detailed analysis about the advantages and disadvantages of both notations. I try to be as objective as possible. Still I know that people won't consider me as being objective, because I'm working for the company founded by one of the inventors of the EPC notation. In that sense, let the flamewar begin ;-)

Points of View

If we take a scientific view on process modeling, we will notice that a process notation deals with different dimensions:

  • control flow specifying the order of process steps
  • data processed in the course of the process
  • people involved in the process
  • resources involved in the process
  • input and output of the process
  • ...

If a BPMN lover says "BPMN is more expressive than EPC", we actually have to ask "concerning which dimensions"? But people usually don't do that and that's how flamewars start...

But today, we want to do it. The good thing is that we can simplify a little bit. We only need to distinguish two points of view:

  • control flow expressiveness 
  • linking to other dimensions

Let's go through both of them and see, which process notation is more expressive in each case.

Control flow expressiveness of BPMN and EPC

BPMN and EPC both use the notion of tokens flowing through a set of interconnected activities (i.e. tasks, functions or steps). In the most simple case, an activity receives a token, performs an action and outputs the token after completing the action. In BPMN, there are some special kinds of activities, which for example repeat the action several times for each token received. Tokens can be split to flow on different parts using gateways (i.e. rules or connectors). For example, a token could be split into two separate tokens or only one token is forwarded based on some decision taken.

This simple mechanism of tokens, interconnected activities, and gateways can be used to model complex flow structures like loops or conditions. Some years ago, some clever people around Prof. van der Aalst came up with the 20 so called "Workflow Patterns" categorizing the different flow structures. Later on, they detailed those patterns further, but this list was too complicated to get any real traction in industry. Therefore, I stick to the 20 workflow patterns.

To evaluate the control flow expressiveness of BPMN and EPC, we check which workflow patterns can be modeled with both notations. As I'm a lazy guy, I don't have to do this analysis by myself, because others have done it before. The analysis of BPMN's support of the 20 workflow patterns was done by Wohed et al. and for EPC by Mendling et al.

The following table shows for both notations, which workflow patterns they support. A plus sign (+) means the workflow pattern can be modeled, a minus sign (-) means the workflow pattern can't be modeled. In some cases, there is a +/- meaning that it is possible to model the workflow pattern even though the notation doesn't contain a direct element for it. So some kind of workaround is needed.


No. Pattern BPMN EPC
1 Sequence + +
2 Parallel Split + +
3 Synchronisation + +
4 Exclusive Choice + +
5 Simple Merge + +
6 Multiple Choice + +/-
7 Synchronising Merge +/- +/-
8 Multiple Merge + +
9 Discriminator +/- -
10 Arbitrary Cycles + +
11 Implicit Termination + +
12 Multi Instances without Synchronisation + -
13 Multi Instances with a priori Design Time Knowledge + -
14 Multi Instances with a priori Runtime Knowledge + -
15 Multi Instances without a priori Runtime Knowledge - -
16 Deferred Choice + -
17 Interleaved Parallel Routing +/- -
18 Milestone - -
19 Cancel Activity + -
20 Cancel Case + -

The table shows clearly that BPMN supports far more workflow patterns than EPC. So yes, BPMN is more expressive than EPC concerning control flow structures. This doesn't come as a surprise, because BPMN was strongly influenced by workflow languages. With the upcoming BPMN 2 version, BPMN diagrams are even directly executable by a process engine. In contrast, EPC was originally not designed to describe processes to be executed on a process engine. Instead, it is meant as a language to capture and visualize business processes.

So it is 1:0 for BPMN. Now, let's take a look how both notations compare with respect to linking other dimensions in the process model.

Linking other dimensions in BPMN and EPC

The control flow of a process just describes how tokens are passed between activities. But a real business process is more than just a set of interconnected activities. For example, a vacation approval process involves people (someone asking for vacation, a boss, and maybe a delegate), documents (vacation request, approval sheet, vacation record), IT systems (intranet portal, project management software), etc.

A process notation must be able to express this kind of information, too. Someone working with a process description has to know in which activities he is involved or which forms to use. Enterprise architecture frameworks such as Zachman, ArchiMate, but also ARIS group such information into different dimensions. The enterprise architecture frameworks don't agree on the number of dimensions, but at least all recognize the fact that it is useful to group similar information. ARIS as enterprise architecture framework suggests 5 dimensions:

  • organization
  • data
  • function
  • process
  • product

For example, the control flow of a process belongs to the process dimension. Forms to be used belong to the data dimension and people involved belong to the organization dimension.

To evaluate how BPMN and EPC allow linking to other dimensions, I used the 5 dimensions above and mapped the elements provided by both notations to them. I have done this analysis for BPMN 1 and for the EPC notation used in ARIS. Please note, the EPC notation available in ARIS contains way more elements and modeling constructs than originally described by the EPC inventors. This is another good point to kick off a flamewar, because you might say it is not fair to compare BPMN to an extended version of EPC. But here I would argue that this is ok, because almost all vendors offering EPC modeling also added their own extensions compared to the original description more than 15 years ago.

Comparison of EPC and BPMN notation concerning linking to other dimensions

The picture above, which is also attached to this post as ARIS Express model, clearly shows that EPC is far more expressive than BPMN concerning linking other elements. Of course you could argue that a pool/lane can also be used to represent an IT system or some other kind of resource. Still, the overall picture doesn't change. There are many elements in EPC notation, which are not available in BPMN at all. For example, in BPMN you don't have elements to express process outcome or to model risks. Also, BPMN doesn't allow you to model KPIs.

Again, this result is not really surprising. EPC is most often used to model high level business processes. Here, it is important to specify things like KPIs or risks involved. On the other hand, such constructs are not important if you want to model an executable process, which was the origin of BPMN.

And the winner is

The analysis shows, there is no clear winner, because it always depends what you are looking for. But does my analysis imply that BPMN can't be used for business process modeling? No, you can use BPMN for business process modeling. But you will need to complement it with additional elements. In ARIS, this can be easily done by assigning a function allocation diagram to a BPMN activity. In this diagram, you can add all those elements, which are not available in the official BPMN notation.

Another implication of my analysis might be that EPC can't be used to describe executable processes. We have shown in the past that this is possible by introducing new attributes, but by also putting in place clear modeling conventions. It might be true that EPC can't be used to express all 20 workflow patterns, but one might also ask if it is necessary to use all of them.

In some weeks, I will post how I would make use of EPC and BPMN in an enterprise modeling effort. Till then, what is your view on EPC and BPMN? Which notation do you prefer? Why do you think EPC/BPMN is useless? It is time to start a fine flamewar!

Note: See this post for a list of other articles about BPMN 2, e.g. modelling the 20 workflow patterns in BPMN 2. You might be also interested to join the BPMN discussion group at ARIS Community.

preview of EPC vs. BPMN - the perfect flamewar (ARIS BPM Blog)

open epc_vs_bpmn.adf (126KB) with ARIS Express