BPMN v/s EPC
Brief Summary
A comprehensive analysis over the topic: "BPMN 2.0 v/s extended Event-driven Process Chain".
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.
Points to Readers
- Readership of this article should ideally be familiar with BPMN (link is external) and/or EPC
- Unless explicitly stated, the 'BPMN' that would be refereed would be its version 2.0 and 'EPC' would mean the extended Event-driven Process Chain.
- When referring to EPCs, we'll use 'gateway' instead of 'rule' and 'activity' instead of function just for the sake of easier comparison
Abstractive Analysis
Expressive Power
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. According to his 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.
Enterprise Architecture
EPC is a process-centric Enterprise Architecture method in itself. And at the time there was only EPC, there wasn't any separation between BPM and EA. 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.
Structural Analysis
Semi-structured processes
A business process model is meant to show some structure and behaviour patterns that are known or at least expected with a good degree of certainty. For processes with high uncertainty, using a notation - no matter how good - would not be as useful as for well structured processes.
There are processes for which activities are known but not their sequence or number of performances. These types of processes are supported by BPMN via ad-hoc sub-process. No similar construct is offered by EPCs.
Advantage: BPMN
Business process notations are used in some way even for managing unpredictable processes. Interestingly, Adaptive Case Management systems such ISIS Papyrus, support both EPC and BPMN which is yet another example that each one has strengths in different application areas.
Exceptions, transactions and compensations
Both EPC and BPMN can support exceptions. However, there is no way to show that something happens during the activity execution in an EPC. Conversely, BPMN is rich in constructs that support exceptions. Those include the boundary events in combination with catch/throw semantics. Situations where an exception could happen everywhere within a process fragment are also well supported by putting the fragment in a sub-process with an exception boundary event. Additional benefits are provided by event sub-processes.
Exception handling is really important. It is true that some modelling limitations tend to support wishful thinking and many processes are suffering of the "happy path syndrome". Now, the mere existence of so many exception handling constructs in BPMN might - well, at first frighten but then - prompt some more realistic business representations.
However, in addition to interrupting events, BPMN supports non-interrupting events that trigger an exception while the process continues - you can show this in EPC with rules (and rule) and events, but the solution in BPMN is more elegant.
Transactions and compensations are supported by BPMN and not at all by EPC.
Advantage: BPMN
Loops
Loops - either standard, parallel or sequential - are a powerful construct in the BPMN notation. They allow to show that a process can run multiple times without the need to draw confusing lines in a model or to repeat process fragments over and over again. In combination with using events or attributes that hold the number of repetitions this is a clean and easily understandable way to model.
Loops can also be shown in EPC notation, even though there are no special markers in the functions that shall be repeated. A modeller has to work with multiple events that are coordinated by rule objects (e.g. "and") to describe the conditions when a loop or repeating activity has ended. This is not impossible but a less elegant solution when the process becomes more complex.
Additionally, BPMN provides 11 standard attributes for handling loop behaviour. When such formalization is needed, things like loop cardinality, data-based conditions and how multi-instances produced by the activity can be specified.
Advantage: BPMN
Managing data
BPMN assumes that all data is freely available within a process and can be used in the tasks whenever needed. In addition to this, data highlights can be shown by either using the data object or the data store for persistent data (even though persistence means "only for this process instance"). The notation is not meant to allow data modelling and the breakdown of data information in specific data models > see chapter 7 of the BPMN 2 specification.
In opposite to this, the EPC notation allows multiple ways to show data in a process: either as abstract clusters or technical terms, that describe an information, or depicted as information carriers, such as documents, CDs, etc. And even as fine as showing relations to classes and attributes. The biggest advantage of using an abstract data object lies in the capability of the ARIS overall method - not only the EPC notation - to decompose a cluster into entities and then into its attributes. These can then be mapped to tables or even synchronized with other dedicated data modelling tools like ERWIN (via a 3rd party interface). Strangely, EPC allows better integration between process models and UML Class Diagrams than BPMN do, while both UML and BPMN are maintained by OMG.
Advantage: EPC
Process notation for ERP Systems
As mentioned earlier, the EPC notation became very popular when the ERP wave took off and companies had the need to figure out and model their processes. The most popular example here is SAP and until today all SAP ARIS customers use this notation to synchronize three levels of process models directly with SAP"s Solution Manager. In addition to this, EPCs can be used to create test cases that get synchronized with HP"s Quality Center for testing (either through Solution Manager or directly via export from ARIS). There is no BPMN synchronization in place as of today.
To further accelerate the modelling efforts, SAP provides two sources of process information that can be included into the blueprint models: The "Business Process Repository" (the transactions) and the "Enterprise Service Repository". Both sources will be enhanced by non-SAP and manual steps in the blueprinting phase of the ERP implementation. But SAP is not the only ERP system on the market - its largest competitor Oracle OEM"ed ARIS in its BPA Suite tool and in that, the EPC notation is also the standard notation. Opposite to the SAP synchronization, the EPCs will be transformed into BPEL models that then will be exported as BPEL and WSDL files that can - after running an Oracle-specific script that transforms the standard BPEL export file into an Oracle-specific format - then be imported into the Oracle ERP system.
An interesting way was presented by Software AG in the "Enterprise BPM" approach at CEBIT this year. Here, it is also recommended to model the business processes in EPC notation, since it is easier to understand for business users and fits into an Enterprise Architecture without workarounds. After the business model is approved, it can be transformed into a logical BPMN 2 model and then enhanced with technical information, for example to show a split of a business process step like "check inventory" in multiple service steps. After the logical BPMN model is ready, it can be pushed into webMethods where the physical BPMN model then gets implemented.
Advantage: EPC
Tools support
An interesting observation nowadays is the marketing hype around BPMN. To a new user, who is investigating which notation/which tool should be implemented the options and sometimes conflicting marketing information are confusing. On the one side you hear that EPC is a proprietary notation (which is not true) that is only supported by ARIS, on the other side, the EPC templates ship with a standard MS Visio installation for years now, while BPMN (in the old version 1.2) was just introduced to the latest version Visio 2010. In addition to this a quick Google search will show dozens of tools for either notation.
Supported WorkFlow Patterns
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.
Conclusion
