Grzegorz Gruchman's picture

Part 1. The Overture

Why Fire and Ice? On the day the Model-2-Execute solution saw the daylight, I realized it is time to take BPMN very seriously. What puzzled me from the very beginning was the issue of BPMN-oriented ARIS modeling within the whole Enterprise BPMN context. I browsed lots of public and internal materials and read a lot of posts, but I still have not found what I am looking for, as the U2 song goes.(i) I decided therefore to begin a journey towards the answers I seek and share the discoveries along the way with others.   

BPMN Attacks. It certainly looks like the age of BPMN has already begun. The largest software vendors - IBM, Oracle, SAP and Microsoft - throw their support behind the latest OMG standard they helped to develop. More and more customers request the use of BPMN in their process management projects. Research indicates that around 50% of BPMN users apply it to define processes from the business point of view. Modeling tools dedicated to BPMN multiply like wild rabbits. Additionally:

  • some ARIS customers think about or already started migration towards this language
  • some ARIS process experts predict that the classic ARIS language will be gradually phased out
  • seasoned ARIS professionals have started to request BPMN trainings

Why such enthusiasm for this emerging process modeling standard? There are several reasons and the support of software giants was already mentioned as an important factor. Many hint also at the similarity between BPMN notation and traditional use of flow charts. I also think the ease of adoption using simple drawing tools has something to do with it. Obviously however, the vendor independence is the main factor of the BPMN momentum. Customers prefer independent standards, because they are free to choose competing products without the danger of vendor lock-in.

The history of technical inventions provides us with examples of superior proprietary products, which lost in terms of market share. Sony scored big with Blu-ray, but its Betamax format for video tapes lost to VHS. Apple’s Mac OS operating system lost to MS Windows. Yamaha’s YPAO audio calibration system lost to Audyssey DSX. Therefore, it seems safe to assume BPMN will dominate the process modeling space in one or two years to come, particularly as there is no other comparable standard available.

BPMN Attacked. However, it is not all champagne and roses for BPMN. Jim Sinur, renowned expert in process analysis, dubbed BPMN as “Business People Many Not understand” and says business users are not happy with BPMN’s engineering-like symbols. He claims also it is better to use other languages for their purposes.(ii) John Everhard, technical director at Pegasystems, says adoption of BPMN suffers partly because "BPMN is too hard for business" as it “obscures the business intent with technical details" and “does not allow business analysts to fully describe the full scope of their objectives and intents”.(iii) What is more:

  • some experts think even the IT professionals will find it hard to master the full BPMN scope
  • some practitioners say BPMN is used mostly for simple process documentation, as opposed to process improvement efforts with real flesh and blood

Why the controversies around BPMN use in business process modeling? The answer can be found in its history. BPMN started as a simple graphical language, conceived to make it possible for business users or analysts to specify IT requirements in a process-oriented way. However, in its latest 2.0 incarnation, BPMN ended up as a graphical programming language for Business Process Management Systems (BPMS). As somebody noted, “...ease of use in [BPMN] process modeling is sacrificed for sheer expressive power.”(iv) Indeed, a quick look at a BPMN poster allows to experience vertigo effects firsthand. However, a solution, at least a partial one, is already available.

BPMN Subsets. The official OMG BPMN 2.0 specifications define three so-called conformance classes, subsets of elements and attributes within the full standard:

  1. Descriptive Class - a minimum set of elements and attributes, sufficient for high-level process modeling and as much as business process analysts can swallow
  2. Analytic Class - encompasses all descriptive elements and additional ones, in toto around half of the full specification required for process modeling
  3. Common Executable - full set of elements and attributes for executable process models

The classes above were defined for modeling tool interoperability. Nevertheless, it is good to know they are based on ideas developed by Bruce Silver. His vision was to define BPMN modeling subsets, methods and styles with different audiences in mind. For process-savvy business users and analysts it is the descriptive class which is most relevant and appealing, as it assumes little or no IT background. The BPMN descriptive subset is also kept to a minimum.

The concepts and phases encapsulated within the Model-2-Execute (M2E) solution are somewhat similar to the BPMN Conformance Classes, except that the classic ARIS process modeling language is assumed for descriptive purposes. The funny thing is that the ARIS and BPMN languages were created with business audience in mind, but there is one fundamental difference. The ARIS language was created to support many use cases in business and process change efforts, while BPMN was developed for IT-based process implementation efforts. Therefore, the ARIS language is more suited for process modeling for the business side, with multiple use and reuse of models in mind. It also seems - contrary experience notwithstanding – that ARIS is also easier for business users to understand in practice.

To BPMN or not to Be? Definitely, to BPMN. I think every ARIS process analyst should become bilingual. He or she should know BPMN, as covered by its Descriptive Class. This will be handy, if the customer asks for exclusive BPMN modeling. If the EPCs are acceptable, such knowledge will be useful for collaboration with process engineers during M2E model transformations.  

I suspect few existing EPCs are candidates for immediate transformation into logical BPMN models. Most EPCs assume informed interpretation by business users, they are also not necessarily complete in terms of all decision-making outcomes, error handling and exceptions. Business users can always rely on informal practices, colleagues, supervisors and common sense, when there is a need to do something extra. BPMS cannot do this, as every software package it is a superfast idiot, to be instructed what to do in every situation. Therefore, I believe almost all existing EPCs need some rework before transformation, when the time comes.

I believe also new EPCs for elementary processes should be M2E-ready. This will make it easier to perform model transformations later. I think this goes well beyond symbols, transformation rules and modeling conventions in general. There is a whole lot of ARIS modeling habits and traditions shaped by project experience. I suspect some of them should be changed for better results. Who knows, maybe there are some implications for the way we decompose processes and structure their hierarchies too.
Transformation of EPC model into BPMN

So, finally, that is the ultimate objective of my blog - to suggest modeling practices which facilitate rework of EPCs or prepare them for automation from the scratch. If the customer prefers BPMN all the way, best practices to support effective process modeling are already available.(v) But if EPCs are to be used, such guidelines on BPMN-oriented ARIS process modeling are missing, at least in my eyes. I have some ideas in this respect and I would like to test them. Till the next installment then.

See also my other posts:


i) There are many articles on BPMN within ARIS Community.

ii) See

iii)  See

iv) See

v) For BPMN modeling best practices: See Bruce Silver, BPMN Method and Style: A Levels-based Methodology for BPM Process Modeling and Improvement Using BPMN 2.0, Cody-Cassidy Press, 2009. For a very good description of BPMN mechanics, see Thomas Allweyer, BPMN 2.0: Introduction to the Standard for Business Process Modeling, Herstellung und Verlag: Books on Demad GmbH, 2010.