One bright hope for business process modeling, developed between 2003 and 2010, was the standard known as Business Process Model and Notation (BPMN). This would be the way to model businesses!  But today, most people use a simple flowchart in everyday use.  Why is that?

Just this week I received an email from a professor in Germany with some process models and with the apology: “Sorry, these are not in BPMN or any formal notation.”   Well, they usually aren’t and it is time to start asking they question: why?

Standard Shapes

BPMN brought to the business process community a standard set of shapes and styles. An activity would always be a rounded rectangle. A solid lines represented control flow from activity to activity. If there was a branch in the control flow then a diamond-shaped gateway would represent clearly that the flow might go in one or a number of different directions. Processes would state and end with a circle shape.

Before BPMN was invented, there were many process modeling tools available on the market which used different styles of drawing the same picture. The differences between the different product representations of the process was often arbitrary. When reading a business process diagram the first question was often to see a list of the shapes and get a definition of their meanings just so that one can start to read the diagram. These arbitrary differences in the shapes was not a benefit to anybody so the industry came together to make a standard notation so that all products could represent an activity has a rounded rectangle and a branch condition as a diamond gateway.

Extension to Semantics

Then BPMN went too far. BPMN started out simply as a notation. That is to say shapes were given meanings, but the precise relationship between the parts of the process was left to the vendor to define. Leaving the semantics to the vendor might on the surface sound like a bad idea but it allowed vendors to implement models with important detailed capabilities to support human work. The BPMN standard committee by that time had moved to the Object Management Group (OMG) which was interested only in diagrams which could be run as simple programs. It seems that the BPMN standard committee:

• envisioned activities as simply a small script or program that was simply executed as a piece of the process.
• modeled human activities as a processing units that completed tasks in a way more or less similar to how a computer does.
• enforced an imperative programming style with sequencing of these pieces of programs served in a command-and-control-oriented model
• viewed the process as a single omniscient program which distributed packets of work out to different machines on the network.

Consider the Source

The OMG is an organization that specializes is designing distributed computing system and has a lot of expertise in that area. The OMG created CORBA which was the first standard message oriented object request broker—a style of distributing computing into objects located on different servers who message to each other.  CORBA was pretty brilliant.  But the OMG did not realize the large difference between how people come together and decide what jobs to do and how jobs are given to computer servers. When you consider the examples given in the BPMN specifications, it is clear that the OMG did not fully appreciate how BPMN diagrams would be used to describe human work in an organization. The OMG expertise in distributing tasks to distributed computer systems tended to push BPMN to be suitable for that end.

By taking BPMN beyond just a notation, and by extending BPMN to be useful for programming networks of server computers, they introduced a number of limitations into the BPMN standard that made it less useful for defining business processes for humans. For example

• the BPMN model from the OMG would assign an activity to a worker but did not offer any way for that worker to delegate that job to somebody else.
• it did not include the idea set a task might be offered to set of people, and one person might then take that job and complete it.
• no concept of being able to send a job back to someone to be corrected.
• no way to comment on a process, or ask someone for advice.

Individual vendors extended in these directions, but that drew them away from the standard.

Today we are left with a BPMN standard which is designed adequately for controlling a large number of servers, but cannot reasonably reflect the work that people in a real organization do. People designing processes with BPMN are often forced to treat human beings as if they are program units which will be submitted jobs and from which results will be returned. So many aspects of what people actually do in an organization cannot be described in these terms. People accept tasks without knowing in advance exactly how they will meet those goals. People advise each other on how to complete tasks and to do work. An expert is often called in for consultation. These are all things that are very hard to draw in a business process diagram in BPMN.

State of the Art

Evidence for the lack of BPMN acceptance in the market is easily seen in the Workflow Management Coalition’s (WfMC) awards that are given out every year. In my role as chief judge for these awards, I have the responsibility to survey all the user cases. I always look through them to assess which of these cases describe their business processes using BPMN and which use some other way of describing the process. Tellingly, less than half of the submissions use BPMN at all and even those that do often also include other diagrams (e.g. basic flow charts or some custom process representation) to help explain the process to the reader. Though almost every BPM product in the market claims support for BPMN, the fact that users rarely use these diagrams in their own documentation is evidence that the BPMN is not what users feel is the best way to describe the process.

I am not aware of a detailed study to assess the suitability of BPMN for use in office business processes, but my experience indicates there seems to be a large shortcoming.  I am not the only one.  Maybe business analysts complain that BPMN misses the target, and have tremendous difficulty programming with it.

Perhaps the flaws and BPMN could be addressed by making it less imperative, and more declarative.  That is is exactly what CMMN tried to do, and we will talk about that in the next post:  Modeling and CMMN.

And if you want to know where this is going, I will be clarifying that in my new book: Beyond the Business Process Model.