The Modern Analyst Blog for Business Analysts

Jarett Hailes
Jarett Hailes

Why I Don't Use BPMN

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

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.

2010-02-08 Flowchart Process Example.png

 

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

 

Like this article:
  6 members liked this article

Related Articles

COMMENTS

Fitz posted on Wednesday, February 10, 2010 10:50 AM
I agree that most business don't grasp the nuances of BPMN. One of the problems, or opportunities, is linear thinking. Most business and, for that matter, IT customers are not process oriented - they are task oriented. Most business processes are not as linear as knocking down a row of dominoes.

To your point on use of lanes, most processes involve concurrent tasks by other entities or technology. In order for business customers to truly understand and, indeed, manage these processes, we need to educate them on the processes and the opportunities for improvement.

Presenting a traditional flow chart to diagram the process can be followed by a more detailed BPMN drawing, if necessary, to illustrate the process in more detail. While taking a little more time, I find that this is useful when an opportunity for improvement or point of failure can be pointed out that the flow chart did not show. Otherwise, I use BPMN for my analysis to analyze the processes or business model, etc..
Fitz
Leslie posted on Wednesday, February 10, 2010 6:41 PM
Not a BPMN expert; my preference is use cases, supported by activity diagrams, but there is a certain similarity between BPMN and activity diagrams.

So, I have 2 comments:
1) I would not show a use case activity diagram to a customer without first preparing them with a textual description of the activities that they are about to see.
2) In the flowchart diagram, how would you show the customer asking for a drinks menu 'at the same time' as asking for the specials menu?

There are reasons why flowcharts were dropped in preference of BPMN for business modeling.
Leslie
Jarett Hailes posted on Wednesday, February 10, 2010 9:05 PM
Thanks for your comments!

@baldrick - If there's a potential for concurrent or parallell activities by one actor you can place all the possible activities between two lines (in Visio known as 'Parallel Mode'). However, if there are several possible activities but only one or more will actually occur I would use a Sub-Process/Pre-defined Process marker in the main diagram and then have a more detailed diagram depicting the possible options that could occur (e.g. decision gates to determine whether customer wants to order food, drinks, etc.).
Jarett Hailes
Leslie posted on Tuesday, February 16, 2010 5:21 PM
On a similar note, I wrote this yesterday. I really do not know what inspired this .. the idea just came to me early one morning.

Leslie.

http://www.umllmu.com/pages/Blogs/BPMN.htm
Leslie
Leslie posted on Tuesday, February 16, 2010 5:23 PM
OR, since the URL does not display as a hyperlink
-------------------------------------------------------------------
1 Why adoption of BPMN may not be a good idea

This article describes reasoning behind opinions about the direction that I see the BPMN standards heading. (These are purely my own opinions and since I do not have insight into the workings of the BPMN standards bodies, they may contain several misconceptions or even errors.)
1.1 A little BPMN history

BPMN v1.0 was released in 2004. BPMN 1.0 is adopted by OMG in 2006.
1.2 A longer history of Modeling Notations

(A personal experience.)

The 1980’s saw the adoption of Structured System Analysis/Structured Design (SA/SD or SSASD) languages for modeling software. SA was largely based upon Data Flow Diagrams (DFD) and SD upon structure charts. SA and SD are quite distinct notations, with SA, as its name suggests, used to describe the requirements for a system and SD, used to document a design.

The major problem with adoption of SA/SD is that the two methods use quite different notations, and there was no automated way to transfer from one model to the other. Once your Analysis model was complete, the Design model would be handcrafted from scratch and the only link between the 2 models is to capture traceability from the processes in the SA model, to the modules in the SD model. Maintaining traceability becomes a long and torturous process that no-one wants to deal with.

The early 1990’s saw the rise of a new modeling technique to replace SA/SD, named OOA/D. Object Oriented Analysis/Object Oriented Design, is based upon classes and class diagrams that are detailed with operations, attributes and methods. Operations are of a textual nature (but may be described with a formal language, such as OCL); methods are programming language specific and contain the shell for a software procedure and attributes are the data manipulated by the classes. In OOA attributes are a description of the data manipulated by the classes (again maybe using a formal language), and in an OOD model they are described in terms of the language that they will be implemented in.

The major advantage that OOA/D has over SA/SD, is that there is no paradigm shift between the analysis and the design models. Both use a large subset of the same language. This means that traceability may be made almost seamless by simply mapping analysis classes onto design classes.

So where does BPMN come into all this? The answer is UML!

Originally many OOA/D languages and notations were developed; notably Rumbaugh, et al and Booch. A company by the name of Rational, attempted to combine all notations into a single language and the result was the Unified Modeling Language, or UML.UML has since been adopted by OMG. Most of us analysts that are building analysis and design models today are using UML, or a variation of it. A nice thing about UML is that it does not impose icons for the notation describing the language, so that those people that like drawing their classes with rounded outlines or clouds, or colours, still can do so without breaking the rules defined by the UML specs. For many of us, UML was a godsend that put a stop to arguments between people preferring one notation over another in order to describe the same thing.
1.3 BPMN and UML

BPMN appears to have arisen from the opposite end of the spectrum, as it’s name suggests, the business. Now 20 years ago, there was little connection between business process modeling and system process modeling. Over the last 10 years or so, that gap has closed considerably, (the adoption of use cases by UML is a great aid to closing that gap). With the release of the Rational Unified Process (RUP), a method was described for modeling business process using UML too.

But, if business processes and architecture are modeled with BPMN and systems with UML, are we not heading back towards the problematic days of SA/SD?

Where is the traceability between the BPMN model and the UML (or system) model?

Since RUP has shown that UML can be used to perform business modeling and analysis, why do we need another nomenclature, such as BPMN?
1.4 A Solution

Now that I have possibly alienated all those advocates of BPMN, for business modeling, let me try and close the gap between the 2 notations.

As I mentioned, UML does not define symbols for representing it concepts. My guess is that the business is more concerned about the graphical representation of the business modeling concepts than the underlying XML definition. So, if we can find a UML representation for every concept in BPMN and adopt the BPMN icon to represent that concept, would the business really care whether it is called BPMN, or UML, or even BPUMLN?

This is just a start, but what I have done is to go through a list of core BPMN diagram elements and identify a substitute in UML. What I have found in BPMN are:

Events – Are descriptions of things that happen of relevance to the business process. Types are; Plain, Message, Timer, Error, Cancel, Compensation, Conditional, Multiple, Signal, Link and Terminate.

Activities – Are descriptions of work performed by the business. Types are; Multiple, Loop, Ad-hoc, Tasked and Subprocess.

Gateways – Are ways of splitting a flow of events in a process flow. Types are data based, event based, parallel and inclusive. (Complex appears to have no formal definition and therefore I am not considering it.)

Flows – Used to connect the above business concepts in order to show connections between them (In the main flows are directed in order to show the initiator of the connection). Types of flow are; Sequence, Message and Associations.

Data Objects – Are artifacts for capturing data used by the business process.

Swimlanes – Appear to be identical to the UML definition.

Groups – Represent a collection of swimlanes that are associated with a business entity.

Annotations – Ad-hoc textual descriptions of a business process.

Taking each of these BPMN types, the question is; is there an associated UML component that could be used in its place?

Events – UML contains various event types, but they do not appear to be as varied as those in BPMN.

Activities – UML contains the concept of actions, activities and tasks.

Gateways – UML has two types of gateway. The ‘fork/join’ and ‘decision/merge’ gateways.

Flows – UML recognises, process flows, object flows, event and sequence flows and associations.

Data Objects – UML includes objects and classes for capturing data.

Groups – Are a variation of the UML swimlane concept.

Annotations – Also in UML.

So, it appears that BPMN contains a lot more symbols than UML, but no actual concepts that UML does not include. The next question is; for every BPMN element, is it possible to stereotype a UML element including a recognized BPMN icon, such that all of BPMN is defined within UML?

If the answer to this question is Yes; then why not do it!

If the answer is No, then why not extend UML to include the missing BPMN concepts!

Either way, I believe that now is as good a time as any, to think about using a single notation for all of my analysis work.
Leslie
Richard Larson posted on Thursday, March 4, 2010 5:22 PM
Jarett, I couldn't agree more, and I've been saying the same thing about BPMN for years. My opinion is that business analysts can use traditional flowchart symbols for 90% of the business scenarios we face. To the point about concurrent activities, I recommend using the activity diagram fork and join notation. It works fine on a traditional process map.
Richard Larson
Jarett Hailes posted on Friday, March 5, 2010 12:45 PM
Thanks Rich for your comments! Pareto's law does seem to come into effect with a lot of what BAs do - if I find that your basic process flows can't capture the level of detail you need, I ask if it's necessary to capture that detail in such a graphical format. Usually I find that in extremely complicated scenarios going to a written format is much more appropriate and helps out all stakeholders involved.
Jarett Hailes
Howard Podeswa posted on Friday, September 17, 2010 8:49 AM
Jarett - coincidentally I have recently posted a blog comparing specific UML and BPMN modeling elements, with a discussion of pros and cons. Check out the Modern analyst MA Blog "BA ABCs: “B” is for BPMN at http://www.modernanalyst.com/Community/ModernAnalystBlog/tabid/181/articleType/ArticleView/articleId/1539/BA-ABCs-B-is-for-BPMN.aspx
- H
Howard Podeswa
Razvan Radulian, MBA posted on Tuesday, January 17, 2012 12:47 PM
I can see your point.
One thing to keep in mind is that in BPMN there are 3 levels of modeling abstraction:
a. Descriptive
b. Analytical
c. Executable
and that not every model (or components of a model) should go through all 3 levels.
For the "business" discussions (...let's face it, all discussions are/should be business discussions;-).
I strongly recommend reading Bruce Silver's book "BPMN 2.0 Method and Style".
Just my 3 cents opinion,
Razvan:-)
Razvan Radulian, MBA
Razvan Radulian, MBA posted on Tuesday, January 17, 2012 12:49 PM
Oops, unfinished sentence:
For "business" discussions (...let's face it, all discussions are/should be business discussions;-), the Descriptive model(s) may suffice.
Same Razvan :-)
Razvan Radulian, MBA
Jarett Hailes posted on Thursday, January 19, 2012 8:46 AM
Thanks for your comments Razvan. Based on Bruce's comments about descriptive modeling (http://www.brsilver.com/three-levels-of-process-modeling-with-bpmn/) I believe this to be essentially equivalent to what I described above using swimlane flowcharts. If you are ignoring rules for valid BPMN as he indicated in his post, then you are essentially using a standard set of symbols to convey meaning to your audience, which is the same as using flowcharts. I can see the potential advantage of using BPMN if there will be a need to delve into a more detailed analysis using the same models, since you won't have to do as much rework.
Jarett Hailes
Zenny Sadlon posted on Monday, February 6, 2012 7:49 PM
BPMN notation is good for IT system design. Before you get there though, you should surface the business processes the IT solution is to support and do so by using a methodology employing business oriented language and expressing the model in simple notation. The rigorous methodology has been around for quite some time, rebranded as Riva in 2005 (when it was augmented by Process Architecture) by its author, Martyn Ould. "Marty Ould has re-invented process modeling for the real world." - Howard Smith, Chief Technology Officer, Computer Sciences Corporation, European Group. See the title "Business Process Management: A Rigorous Approach".
Zenny Sadlon
Jik Le Shoog posted on Tuesday, February 13, 2018 1:05 PM
How is UML easier to understand than BPMN by non-technical people, really?
Jik Le Shoog
Only registered users may post comments.

 



Blog Guidelines

» What is the Modern Analyst Blog and what are the Benefits of Contributing?

» Review our Blog Post Guidelines.

» I am looking for the original Modern Analyst blog posts.




 

ModernAnalyst.com LinkedIn Group ModernAnalyst.com on LinkedIn: connect with fellow business analysts in order to develop and expand your professional network.
Learn More...

Copyright 2006-2024 by Modern Analyst Media LLC