BPMN became popular. Customers demand BPMN because in their view it’s modern and hence a priori more advanced process notation.

But I also understand process specialists experienced in other notations e.g. IDEF or EPC that refuse to follow the fade blindly and ask to explain why BPMN is better. I understand their skepticism - a new notation must be essentially, radically better to justify the transition, not just look nicer.

So what is BPMN -

Another Notation or The Notation?

It may sound trivial but - it depends on how are you going to use it.

A new notation emerges not to solve old problems. Or, more precisely, a new notation emerges to solve not only old problems. It should be competitive in traditional applications and open new opportunities.

So let’s sort out: why do we model business processes?

Typical Process Notation Applications

1. Architectural drawings

How do we make money in our company? How does process-functions-resources matrix look like? Which business processes are served by which IT systems? If you wish to draw a rectangle, label it with the name of your company in order to expand it into value chain and to depict links between core processes then there is nothing better than IDEF. DFD is viable option, too. But not BPMN, definitely.

2. Process drawings

If you wish to understand and manage how employees participate in particular processes in order to better manage the company or to pass a certification then there is the widest range of process instruments available: from semi-formal workflow diagrams to EPC. BPMN is an option, too. Probably not worse than other options but not better either.

3. Workflow automation

If software development is at first place and a process is just one aspect of the software then UML would be a natural choice. EPC has strong position when it’s not development but ERP implementation and customization - you’ll be able to translate process drawings e.g. into SAP.

4. Direct execution

Translation of process diagrams into software code works fine under assumption that it’s a one-way path: analysts draw process diagrams first then programmers implement the diagrams in a software application and finally we go into production.

The only question is whether such approach is realistic?

It became a common opinion recently that this key assumption isn’t met for a wide range of business processes, especially cross-functional and end-to end business processes.

Business processes change and they change often enough - say from once per week to once per quarter. And here we get a well-known -

Round-Trip Problem

Step 1. Business analysts question subject matter experts and depict the knowledge in processes diagrams.

Step 2. Programmers translate diagrams into a software code.

Step 3. A system takes off and goes into production.

Step 4. A business process changes. The regulator changes rules, competitors raises the bar, clients’ expectations grow - a process must be changed because stagnation is death.

Or even more often, its our view of a business process that changes - we understand how to do the job the best only with operational experience.

Anyway, the time comes to review the process so analyst get its scheme from the archive to modify (optimize, align with reality - whatever). But things become tough at this moment:

1. Programmers deviated from the initial diagram while developing the system - first a little then more a more during the implementation.
2. While it’s possible to translate a process diagram into software code automatically during the first run, translation of changes is performed manually and complexity of the translation varies from “high” to “forget about it”.

Step 5. Programmers have taken a business process into their arms not to let it go away anymore. All business process changes should be addressed to IT and they implement your wishes to the best of their understanding. Forget about business process visibility that graphical process notation promised - the process is “buried” in a software code. Business analysts and hence business does not control the process anymore.

This situation is uncomfortable for IT as well as business because IT cannot really handle this weight. At the end of the day we’ve got a set of collisions known as business-IT divide:

• «it’s all because certain people don’t know what they want»
• «no it’s all because certain people can’t implement what’s requested»

No matter what notation is used: it may be UML translated into C# or EPC translated into SAP. It even may be BPMN translated into BPEL so BPMN is not a panacea by itself!

We could start a theoretical discussion here about possible solutions but if a problem is here for a decade then it’s basically an experimental fact for me.

What can we do about this problem?

Keith Swenson dissected the problem in 2009 in the article “Model Strategy: Preserving vs. Transforming”.

The point is that the problem outlined above only relates to systems that transform the process model: business deals with process schemes depicted in graphical notation while IT deals with software code.

The alternative are systems preserving the process model. Business analysts deal with graphical notation here too while IT deals with process attributes that specify it’s execution and with software code explicitely tied to the model. The key difference is that both parties work not with two separate but with a single physical model, separated into levels only logically. Analysts are fully responsible for the process scheme while programmers specify the model at the lower level and don’t intervene into other party area of responsibility.

Well it’s somehow idealized picture - it’s not unusual for a programmer to request a business analyst to amend a process scheme to make its execution possible or even to make such change himself. But the point is that a process diagram remains familiar for a business analyst (and therefore for business) so he/she remains involved into a process work.

The concept of a directly executable business process in brief -

What You Model Is What You Run

This concept has gained acceptance not long ago. Couple of years ago there were vivid debates between pure BPMN vendors and proponents of using BPMN for modeling and BPEL for execution (a model transformation variant), including the industry heavyweights of SAP, IBM, Oracle.

Now what we observe today:

• IBM acquired Lombardi (model-preserving BPMS based on BPMN) and made it a flagship BPM product.
• Oracle acquired BEA (AquaLogic BPMS is BPMN-based and model-preserving) and made it a flagship BPM product.
• SAP announced SAP BPM (BPMN-based model-preserving system), pushing NetWeaver aside.

Results

Applicability of different process notations in a table format:

	Workflow	IDEF	DFD	UML	EPC	BPMN	BPEL	Total:
Architectural drawings	-	+	+-	-	+-	-	-	2
Process drawings	+	+-	+-	-	+	+	-	4
Workflow Automation	-	-	+-	+	+	+	+	4.5
Direct Execution	-	-	-	-	-	+	+-	1.5
Total:	1	1.5	1.5	1	2.5	3	1.5	12

This table demonstrates that the optimal notation selection depends on the task at hand:

• if you are going to model the architecture and processes without intentions of execution then IDEF+workflow or IDEF+EPC certainly would be better choice than BPMN
• range of selections is the best if you are interested in one-way automation
• if you are interested in direct process execution then there is no real alternative to BPMN

Multi-purpose BPMN

As can be seen from the table, BPMN offers the widest range of applications - 3 from 4. This is an important advantage because you don’t always know how will your process initiative evolve.

E.g. we started with drawing process for documenting purposes and then move to automation or direct execution. Obviously it’s better to stay within one notation when such things happen, just by increasing the level of details. Notation change doubles expenses to instruments and competence and what’s even worse, there become two truths about the same process.

If BPMN were locked up just on executable process it’d be called BPEL and it won’t get wide acceptance.

However it would be oversimplification to say that executable business process is always better than  modeling for the sake of documenting and optimizing. Only a relatively small amount of processes should be brought to this level while the majority should be left as non-executable drawings.

That is, one should select 5-10% of processes that are most important for business and make them executable. These are the processes directly affecting company’s bottom-line.

Bringing every process to this level is simply not doable - for the majority of processes a simplified BPMN palette should be used. Comparing to modeling for the execution, the resulting diagrams are much simpler and easier to understand for business while the modeling efforts decrease dramatically.

So BPMN is two notations in one:

• use full BPPMN palette if modeling for execution
• use basic BPPMN palette if there is no need to detail a process to the executable level

This point is often overlooked by those who criticize BPMN for complexity. Sure it’s complex but only when you model an executable process where BPMN effectively doesn’t have an alternative. But if you face a simpler task then BPMN isn’t more complex than a workflow diagram and in contrast to EPC, basic BPMN palette is intuitive and doesn’t require a formal training for understanding.

Conclusions

BPMN has points to criticize, e.g. eclectic design or lack of tools to model high-level (architectural) diagrams. But this notation has crucial advantages, in my opinion:

1. BPMN is the only common notation today that fosters the concept of directly executable business process.
2. BPMN is two-in-one kind of notation: full palette for executable diagrams and basic palette for simplified, intuitive ones.
3. Standard version 2.0 publication caused industry consolidation and pushed BPMN into mainstream. BPMN for process management today is like SQL for data management 20 years ago.

The boom around BPMN can only be understood by getting beyond traditional process application - by realizing what else can be done with business processes apart from drawing. If the concept of executable business process is new to you then get acquainted by a model-preserving BPMS like Bizagi BPM Suite. IBM BPM or Oracle BPM Suite would do the job too but Bizagi is much easier to download and install.

BPMN is competitive in traditional applications but no more than that, so don’t expect radical advantages there. If you are comfortable within this range or if IT frightens you then don’t bother - probably BPMN isn’t for you.