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:
- Descriptive Class - a minimum set of elements and attributes, sufficient for high-level process modeling and as much as business process analysts can swallow
- Analytic Class - encompasses all descriptive elements and additional ones, in toto around half of the full specification required for process modeling
- 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.
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:
- Fire and Ice. Part 2. BPMN Conversations
- Fire and Ice. Part 3. BPMN Collaboration
- Fire and Ice. Part 4. BPMN Process Models
Reference
i) There are many articles on BPMN within ARIS Community.
- Introduction to BPMN.
- Comparison of EPC and BPMN language
- BPMN vs. EPC revisited, part 1
- BPMN vs. EPC revisited, part 2
- Introduction to M2E
ii) See http://blogs.gartner.com/jim_sinur/2010/08/30/bpmn-for-business-professionals-burn-baby-burn/
iii) See http://www.cbronline.com/news/pegasystems-says-bpmn-20-is-too-hard-for-business
iv) See http://www.bptrends.com/publicationfiles/05-08-ART-BPMN%20Survey-Recker-JR%20final.pdf
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.
Well said. I think this is overall a fair treatment of BPMN. However, you fail to mention a key point. BPMN is, by intention, outwardly familiar to business people, since it adopts the basic look of traditional swimlane flowcharts. That is both a blessing and a curse, as it leads people to think they can use it with zero training. But BPMN's value comes from its defined semantics and rules and expressive power beyond what you get in flowcharting, and you need training for that. Can you imagine people using ARIS with zero training? Ha ha! I thought ARIS training was measured in weeks. I would bet that a business person after 2 days of my training would understand BPMN better than they would understand EPC after 2 days of ARIS training.
In reply to @Bruce - now you are turning by Roland Woldt
Thank you for comments. I am certainly convinced about the expressive power of BPMN 2.0, I am also aware it has very precise syntax and training is necessary. As for the classic EPC language, the basic constructs/symbols are simple and intuitive, that is my training experience. The language is also very flexible, it has just a few rules. Nevertheless, I admit business users have issues with the concept of ARIS events.
Basic ARIS training takes 2 days and is sufficient for regular process project members. Most of the time is devoted to many basic model/diagram types, as well as to operations on models and repository. I understand BPMN training is different, as much more time is devoted to its syntax, semantics and rules.
As for the swimlanes, I planned to elaborate on this topic 1-2 installments from this one.
I fear the discussion (EPC vs. BPMN) leads a little bit into the wrong direction.
The real gap is not between EPCs and BPMN - even 2.0 - models the real gap is between informal and formal models.
EPC can be informal like a Winword .doc or formal and BPMN can be informal or formal too.
(I mean business can not have the freedom of an action painter and expect that IT interprets)
If business/architects want to use EPC I'm fine with that BUT they have to be formal - at least the EPCs which should be on the runnable level.
which means we must communicate that we check certain rules on these kinds of EPCs to be faster in the transformation to the runtime which is of course of value for the business
(a model driven approach)
For a process-oriented enterprise there's no way out of bringing the two groups very close together discussing and modelling the process up to the runnable level controlled by the process-owner
That's the real challenge because of politics but the only way to get faster.
As an IT-person I off course would go the way with BPMN 2.1 ?
2.1 because BPMN urgently requires a strong link to the datamodelling - part by means of UML and or XSD.
Who is able to validate the dynamics (process) without having a look at the statics (data) and vice versa ?
(That's why we invented OO - didn't we ?)
Hi Augustinus,
sorry for delay in my feedback. You wrote something very important - "... If business/architects want to use EPC I'm fine with that BUT they have to be formal - at least the EPCs which should be on the runnable level. Which means we must communicate that we check certain rules on these kinds of EPCs to be faster in the transformation to the runtime which is of course of value for the business".
That is exactly the top-level purpose of my blog. My assumption is (1) ARIS process analysts should know the basics of BPMN 2.0 on descriptive level (2) Some techniques and a certain ARIS modeling style should be developed, to facilitate the transformation of EPCs into BPMN 2.0 (3) EPCs targeted for transformation must observe BPMN-derived formal rules.
My blog just got started and right now the topic of the month is an introduction to business-oriented modeling using BPMN 2.0, to provide a common language and concepts for business and IT communities. The other topics will follow.
GG
PLease be advised, the second installment of my Fire and Ice is available. It can be found under this link: http://www.ariscommunity.com/users/grzegorzgruchman/2011-09-07-fire-and-ice-part-2-big-picture . GG
