I have been developing business applications for many years now, and I know for sure that workflow is an essential part of any business project and that if you’re dealing with workflows, you have to deal with BPMN, it’s inevitable. BPMN (Business Process Model and Notation) is a standard for business process modeling which provides a graphical notation for specifying business processes. It is a useful system for business analysis, but absolutely unhelpful if used for other purposes.
In 2010 Jim Sinur wrote an article «BPMN for Business Professionals: Burn Baby Burn», in which he explained that BPMN is simply not suitable for business professionals. It provoked a heated discussion, with many experts supporting Jim. Keith Swenson for example says that BPMN is not useful to the typical worker in the workplace, and Chris Adams in his response to Jim elaborated that while BPM can ultimately lead the horses to water….it cannot make them drink.
I must confess that it is absolutely true! In my experience I have never met business professionals (IT personnel excluded) who didn’t mind learning to work with BPMN. Most people don’t like the idea of mastering a new application. They need get things done faster, better and more easily, using familiar tools and technologies.
Taylor Leighton gives the following example in his post on the topic (and I must say that I have had similar experience in my line of work):
“I recently returned from NYC where I had a conversation with a very frustrated CIO new to his company. One of his first challenges was to settle the internal havoc and chaos in the company regarding how their flagship process was to be executed. This is an enterprise process spanning multiple departments and included the company’s sales, marketing, professional services, and executive teams.
He thought he was doing the company a service by finally documenting the process visually….and he invested in the BPMN notation to do this. He presented the map to the company, stating proudly that the enterprise process was finally documented and in visual format. Unfortunately for him, all of the business people in his office simply took the BPMN representation as “pseudo-code”, and rather than the people argue over the actual flow of the process, they asked a million questions about the shape and icons used. He was resigned to having to go back to the drawing board and “simplify” the model”.
Besides that we must not forget about using BPMN2 in software engineering. Its specification pdf file is 538 pages long. Who would ever read it up to the end!? Even a 175-pages long C# Programming is a tough manual to read, but 538!? Mission impossible.
That is why I am strictly against using BPMN2 in software development. And here are my reasons why:
- your business users won’t be able to manage a BPMN modeler and are gonna beg for a simpler tool;
- it is a very complex file format, impossible to use without a graphic design tool (which is often required when developing complex cases);
- different systems interpret this standard differently; you can upload files from one system to another and from one designer to another, and both processes will be executed differently;
- BPMN2.0 won’t let you code and develop faster.
All in all BPMN is a perfect tool for analysts, but think twice before using it in software development or letting business users work with process schemas.
In my company we learned this lesson the hard way, so that in the end we had to simplify BPMN and turn into a unique product any user can work with.
And what do you think about using BPMN2?
