BT

Will Business Adopt BPMN 2.0?

by Boris Lublinsky on Sep 15, 2010 |

 

Many publications have established that one of the main prerequisites for success of the Business Process Management (BPM) undertakings is close cooperation between business and IT. One of the ways to ensure such cooperation is the development of the Business Process Management Notation (BPMN), which is supposed to be a process definition language shared between IT and business. BPMN 2.0 has introduced a lot of constructs allowing to directly define process execution and as a result has been adopted by several vendors as a run-time language for BPM. But many analysts think that such an enhanced execution support makes the language too complex for business users. Jim Sinur asserts that BPMN is demanding too much from the business people:

BPMN for business professionals is just not up to a business level of need. Some folks think that BPMN is good enough for IT and it should be good enough for business professionals. I think the former is true, but the latter is way off the mark. IT professionals can’t really expect business folks to understand cryptic/standard formats when they really want to see a real representation of their processes with desirable icons; not engineering Icons. It’s kind of like someone saying "let them eat cake". It is this IT arrogance that could sink BPM technologies... BPMN really stands for "Business People May Not... understand"

Sinur’s blog post opened a flood gate of responses. Scott Frances, for example, considers that we can ask business people to acquire new skills as long as they are asking IT people to improve theirs:

Respectfully, I think Jim is letting the business off the hook.No need to learn any new skills over there on the business side, just draw something on a napkin and hope it turns into a process. Just make up any old iconography you want, no problem if no one other than you can understand it (you know, the value of standards is that more than one person or team can understand what is produced)... At a time when we’re asking IT to learn new skills and to be more business oriented, is it too much to ask Business to learn new skills to support process improvement?... The problem isn’t that BPMN, as a notation, is too hard. It is that too many people think that BPM starts and stops with BPMN! There is so much more to managing business processes, and improving them, than BPMN.

Keth Swenson notes that most of the enhancements to the new version of BPMN are for developers, not for business people, turning it into a graphical programming language for processes. He questions whether vendors will move from BPMN 1.2 to 2.0 if their focus is on modeling rather than execution. In his opinion:

For server integration style BPM, otherwise known as Enterprise Application Integration, or Web Service Orchestration, there is a reasonable advantage in getting the additional formalism of BPMN 2.0 for this kind of programming. For human style BPM which uses diagram to depict the actions of organizational members, instead of servers, may find that the additional complexity of BPMN 2.0 only adds additional complexity without sufficient benefit to the users

Answering to Swenson’s comment, Sandy Kemsley strongly disagrees with him:

I think that Keith is throwing the baby out with the bathwater here: although a lot of new constructs have been added that make BPMN more useful for developers, that doesn’t make the basic subset inappropriate for business people who are already mapping their business processes with flowcharts. In the absence of any specific direction, I most often see business people (and business analysts) use flowcharts to represent their business processes; introducing them to the simplest BPMN subset will at least put some standardization around those flowcharts so that there’s no confusion over the shapes used on the diagram, and to reduce some of the spaghetti around flowcharting events.

Neil Ward-Dutton takes a middle ground approach:

... the applicability of BPMN depends on a number of factors; saying that BPMN (especially BPMN 2.0) either is, or is not, suitable for "the business" is too simplistic and black/white. It’s like saying Cloud Computing is the future of IT. Firstly it supposes that we have to talk about BPMN as an all-or-nothing proposition; secondly it supposes that "the business' is some kind of homogeneous organization with one set of skills, experiences and inclinations... there’s significant evidence to suggest that a core subset of BPMN symbols are absolutely usable by business analysts with experience in high-level analysis and design and provide great results in terms of delivering a common language across multi-disciplinary teams.

Yes, the majority of the new features in BPMN 2.0 is aimed to make it an executable language and, yes, the complete standard is fairly complex, but as Bruce Silver explains in his book. BPMN 2.0 can be used on three different levels - descriptive, analytical and executable. If we assume that businesses will start from level 1 comprising 10 main icons, that can’t be too complex. But the advantages of a formalized standard language understood and interpreted the same way by both business and IT are huge.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

It's all about the silver bullet utopy by Sébastien Arbogast

For me the problem is to consider that all business people are similar, and all IT people speak the same language. Asking everyone to read and write BPMN is like asking all European Parliament members to speak Esperanto, it won't work. What really matters is to define conventions so that all the people that speak roughly the same language don't use different dialects of it. Certain business people can understand and use BPMN, and certain IT people can do that too, but then we need translations between BPMN and more Domain Specific Languages.

Isn't it Business Process Modelling Notation? by James Zhuo

Doesn't BPMN stand for Business Process Modelling Notation? See www.bpmn.org/

Re: It's all about the silver bullet utopy by Tom Baeyens

For me the problem is to consider that all business people are similar, and all IT people speak the same language. Asking everyone to read and write BPMN is like asking all European Parliament members to speak Esperanto, it won't work. What really matters is to define conventions so that all the people that speak roughly the same language don't use different dialects of it. Certain business people can understand and use BPMN, and certain IT people can do that too, but then we need translations between BPMN and more Domain Specific Languages.


I couldn't agree more. Well said. Business analysts come in different flavors: they range from completely non-tech over having done some tech long ago to knowledgable about today's software architectures. Similar range you're find in developers.

BPMN 2.0 will make it easier to bridge the gap between business people and developers. Depending on the flavor of business people and developers involved, that gap will be big or small. If it's small enough, a single model for both business people and developers can work. If the gap is too big, that approach doesn't work and the BPM solution just needs to facilitate the collaboration between two distinct worlds.

Tunnel vision in the BPM market by Tom Baeyens

This post triggered me to write my thoughts about the blind spot of the BPM market: Tunnel Vision In The BPM Market

Regards,
Tom Baeyens
Activiti
Alfresco

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT