First off, let me just say that I really like the BPMN standard, especially the 2.0 Beta specification.  I find the notation to be a powerful and expressive language that takes into account not only the standard elements in business processes but also considers all sorts of interesting possibilities that may arise.  I think the new Choreography and Conversation diagrams and additional event types open up new ways to describe intricate processes and collaborations between various individuals and organizations.  Indeed, BPMN allows you to graphically model almost any situation that you can find in a business.

And I rarely get to use it.

According to the BPMN 2.0 Beta spec, there are two goals for BPMN.  One goal “is to ensure that XML languages designed for the execution of business processes, such as WSBPEL (Web Services Business Process Execution Language), can be visualized with a business-oriented notation.” 

The other goal “is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes.” 

While BPMN does extremely well with respect to the first goal, I believe it does not live up to its second goal.

Business People Don’t Get BPMN Right Away

Whenever I stick a non-trivial BPMN model in front of actual business customers, I always get at least some questions.  The number of questions varies depending on their sophistication and the number of times they’ve seen a BPMN (or similar) diagram before.  BPMN leverages the typical flow-chart diagramming that nearly all business people are familiar with, but they’ve made several changes that make the their models anywhere from slightly confusing to downright unreadable for the layperson.

For instance, one of the most common questions I get is with respect to the fact that each pool has its own start and end processes as well as process flow lines.  If there is interaction across the pools then a message flow is used.  Most business people get overwhelmed with the additional flow lines and have trouble following the overall process path – usually when a hand off occurs between individuals or organizations you want to follow whoever received the handoff.  With BPMN this is not always readily obvious since all pools continue along their own process flows.  I could get around this by using only lanes instead of pools since lanes are not considered to be running their own processes, but then I’m not using lanes correctl.  Each pool is defined as a “separate business entity or participant” while a lane is used to “separate the activities associated with a specific company function or role.”

BPMN Process Example

Other times people are thrown by the exceptions or compensation processes, since they are usually shown on the same page (although not necessarily).  While I personally like these artifacts I often spend more time explaining why they are there than reviewing the accuracy of the actual process itself.

Over time I’ve been able to get some clients used to the notation, but if a new stakeholder is brought in I’m back at square one.  To me this shows how BPMN is not ‘readily understandable’ by the vast majority of business people involved. 

BPMN is a Great Precursor to BPEL

I definitely see how BPMN is an excellent tool to use if you’re preparing to leverage the Business Process Execution Language (BPEL) and have a BPEL Process Manager solution in place to automate business processes.  The BPMN spec indicates that traditional models create “a technical gap between the format of the initial design of Business Processes and the format of the languages, such as WSBPEL, that will execute these Business Processes.”  BPMN has really been designed to address this gap, but has focused on the technical implementation side by sacrificing out of the box understandability for any given model. 

From a solution standpoint this makes sense – if the goal is to in the end have automated business processes then you need to ensure that your model can translate into a language that is computer-ready.  BPEL has been around for almost 8 years now and has gained a level of acceptance by software providers and businesses.  Combined with the demand for lower labour costs wherever possible and there is clearly a need for non-programmers or extremely technical personnel to be able to leverage a graphical description of processes.

Like any other technically-driven language, BPMN is relatively generic, robust and flexible.  In order to achieve its level of flexibility the language must be inherently complex to handle all the possible situations that could fall within the scope of the language’s use.  While this is great from an implementation perspective it takes away from the ability for someone with little knowledge about the notation to be able to read a diagram.

When to Stick With the Tried and True Notation

In most situations (performing current state analysis, working through future state processes, validating requirements, etc.) that involve business people interacting with diagrams BPMN is a bit of overkill.  When I’m not trying to create an automatable BPEL-driven business process I find that business people can almost universally understand a flowchart.  This is something that most individuals have had exposure to at some point, and even if they haven’t there are so few different diagramming objects that it’s easy enough to pick up quickly (at the very least you don’t need a 226 page reference guide to figure out how to understand the chart)

While a flowchart may not be able to elegantly model complex business processes as well as BPMN, you can still get the job done by breaking up complex situations into several smaller component diagrams and then using the link object to move between the components.  I find that this not only helps me ensure that each component chart is clear when I’m building the model, it also helps me work through specific sub-processes or exception cases with clients when I’m reviewing the details with them since it’s easier to focus on a single, relatively straightforward chart at a time.

Flowchart with Swimlanes Example

One part of BPMN that I’ve brought over to the flowchart world and use nearly every time is the swimlanes artifact.  Having swimlanes helps everyone clearly understand the responsibilities and activities that each participant in the overall process plays, where the hand-offs are and what kind of information is going back and forth.  I’ll often attach document or data elements when the flow goes across the lanes to show the details of the hand-off, which embeds a lot of the information you would typically find in a Data Flow Diagram (DFD) for the given business process.  In fact, if you wanted you could roll up these messages and create a DFD if you have a need for that type of structured analysis.

While BPMN is a great way to prepare a business process for automation, it may not be the best choice when it comes to interacting with the business itself to document, verify and envision business processes. 

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com