BPMN vs. EPC revisited, part 1
There were several posts and discussions on the topic of "BPMN vs. EPC". One of them is quite comprehensive and its discussion thread very interesting. But there are still many important points untouched and I'd like to share some of them for those facing a choice of business process notation.
That doesn't mean that there aren't other options. But they have quite lower utilisation potential and/or address different needs. Certainly if UML is used, a combination of activity, statechart and sequence diagrams would do, more or less. And then most of what EPC offers could be expressed with ArchiMate. Speaking of process modelling notations it's worth mentioning also Petri-Net which has better execution semantics than BPMN (while that's the main claim of BPMN) but is not at all adopted by the business and generally gets little attention outside academia.
So, having the long and successful history of EPC usage and the current growing popularity of BPMN, it seems a valid set of options. And there is a demand for more information to support decisions related to the choice of process notation, especially (naturally) among ARIS users.
The ideas here are based on the conviction that a single notation for business processes which can equally serve the requirements for analysis, process automation and enterprise architecture is achievable. There are some strong points by the advocates of the concept that the choice of the notation should be based on the modelling objective and it's fine to have many languages. However, if one notation is able to serve the majority of applications, then it would eventually be a better means for communication and will require less learning and maintenance. Furthermore, when efforts for improvement are focused on one language, there is higher probability of getting it better sooner.
Having said that, I still hope that the information in this article would support not only XOR but also AND decisions. Another way to help such decisions would be to make a condition comparison, with a lot of "it depends", if-clauses and suchlike. That is a valid approach but it will be avoided here leaving the "it depends" as conclusion for the readers, rather than using it as a way to structure the comparison. And speaking of structure, it would be quite loose - a dozen of short sections that could be read in any order.
One more thing before the actual comparison. I assume the readership of this article is familiar with BPMN and/or EPC. And, unless explicitly stated, by 'BPMN' I would refer here to its version 2.0 and 'EPC' would mean the extended Event-driven Process Chain. And when referring to EPCs I'll use 'gateway' instead of 'rule' and 'activity' instead of function just for the sake of easier comparison. Hope you don't mind.
BPMN features over a hundred modelling constructs. Most of them are sub-types of the three main flow elements. They are primarily focused on describing workflow and collaboration. As it can be expected, BPMN has much more expressive power than EPC in these two areas. The control flow elements of EPC are only five.
There are different ways (and viewpoints) to measure the expressive power of modelling languages. One of them is by workflow pattern analysis, another by ontology-based analysis and yet another by measuring the ability to integrate different aspects of Enterprise Architecture.
Workflow pattern analysis has been applied for comparison of BPMN 1.1 and EPC among other modelling languages by Nick Russell et al in 2006. According to this research, BPMN natively provides clear support for 24 of 43 patterns, while EPC supports only 10. Of course the real implications of that could be seen if there is a reliable statistic on the frequency of occurrence and the importance of unsupported patterns. Still, when you need to describe a workflow with more rigour and provide a model that is closer to reality, BPMN is the way to go. This is also confirmed by a more recent comparison between BPMN and EPC on the twenty main workflow control patterns.
Applying ontology-based analyses like the representational analysis of process modelling techniques, confirm expressive superiority of BPMN over EPC on the way it facilitates clear descriptions of real-world domains. (For those who don't know and/or don't care about this type of analysis, let's just say that evaluation support of workflow control patters is not the only way to measure expressive power.)
However, if measured by the ability to integrate different aspects of Enterprise Architecture, EPC is much more expressive than BPMN. There will be some more information about this further in the post.
When evaluating the expressive power, it's worth reminding that expressiveness comes with the price of increased apparent complexity. This reduces comprehension and communication effectiveness, especially among model readers that are not experts in process modelling.
Readability and efficiency
Which one is easier to read? And by whom?
That's probably quite subjective. Some find BPMN event symbols more intuitive than the big hexagonal symbols for EPC events. Others defend EPC events for they somehow make you put a name unlike 'none' BPMN start and end events which are quite often left unnamed. Both are valid points and worth considering.
There is some research on the subject of process diagram readability but not much. This one applies cognitive effectiveness criteria based on the 5 principles introduced by Moody and Hillegersberg: representational clarity, perceptual discriminability, perceptual immediacy, visual expressiveness, and graphic parsimony. It seems EPC is doing a bit better there than BPMN.
When it comes to efficiency, BPMN diagrams are more compact than those of EPC expressing the same content. That's not only because of the relatively smaller event symbols. EPCs require events after OR and XOR gateways, while in BPMN their semantics is conveyed by the attributes of the sequence flows following the splits. Moreover, the allowance of implicit events in BPMN as well as conditional sequence flows can make some diagrams really compact. Sometimes, however, this increased efficiency can lead to erroneous comprehension.
A smaller number of visual elements can indeed increase readability simply because there is smaller amount of things to comprehend. In other cases more compact diagrams such as the ones using implicit events and/or conditional sequence flows are not necessarily easier to read. They can take more time to understand and are prone to misinterpretation.
Resources assigned to activity
Quite often one single activity involves more than one participant at the same time. EPC not just supports this but offers more than ten different connection types between participant (organisation unit) and activity (function).
In BPMN on the other hand, assignment of multiple resource to one activity is natively not supported at all. There are some attempts to do it like those proposed by Michele Chinosi in one of the chapters of BPMN 2 Handbook. I'm not convinced by those workarounds.
Generally EPC is superior to BPMN when it comes to resource analysis, not just of human resources, but also in integrating data and system objects that can be further detailed in other Enterprise Architecture views. More on that in the next section.
One good solution offered in ARIS to solve this is to assign Function Allocation Diagrams (FAD) to BPMN activities. FADs can contain objects like organisational units, application systems, services, risks, data and more than one hundred other objects. But that's a specific extension and it's more or less barrowed from EPCs as FADs are introduced to reduce the complexity of rich process chains.
EPC is a process-centric Enterprise Architecture method in itself. I personally don't see the point of separating BPM and EA. And at the time there was only EPC (sorry, I don't count flow-charts and suchlike as a way to describe processes), there wasn't any separation between BPM and EA. And it's strange when aiming IT/business coherence how first EA was separated from BPM and then how BPM became BPA to allow for business process execution to get the BPM label. Anyway, let's not go into this here. The talk is about business process notations. Those who believe there should be a rigorous way to integrate process control flow with data, systems, products, services and infrastructure, will have that natively supported by EPC.
BPMN is not made for that. But we can't say it as an objective not achieved. There wasn't such objective in the first place. One way to partially support some EA aspects is by adding artifacts (but unfortunately not different types of associations). Another is to integrate with some EA notation such as ArchiMate. What would still be missing is the support of the motivational domain. And that's another advantage of EPCs. There you can link activities to requirements, objectives and KPIs.
Well, that (+comments, hopefully) should be enough for Part 1. Next one will deal with handling of end-to-end processes, exceptions, sub-processes, messages, unstructured processes, loop, data and more.
Special thanks to Roland Woldt who reviewed the draft of this post and provided some valuable advice.