The Modern Analyst Blog for Business Analysts

BA ABCs: “B” is for BPMN

#2 in the series: “B” is for BPMN
This blog continues a series on BA tools, based on my book “The Business Analyst’s Handbook”. In each blog, I move through the alphabet, highlighting a BA tool that begins with the letter of the day. Today’s letter is “B” – for Business Process Modeling Notation (BPMN). BPMN is the name of a standard often used for modeling business processes. The diagram covered by the standard is called a Business Process Diagram (BPD).

Example:
Figure 1 is a BPMN BPD that describes the process for reserving a room in a private-members club. The process begins when a member requests a reservation for a specified date. A reservations agent determines the rate and then takes one or more of the followings actions:

If the request included a query about basic rooms, the reservations agent checks the availability of basic rooms.

If the request included a query about deluxe rooms, the reservations agent checks the availability of deluxe rooms.
The slash on the flow marked “Query basic rooms” is a default, indicating this flow is selected if none of the conditions are true.

Next, the member selects a room. When the member’s response is received by the reservations agent, one (and only one) of the following actions is taken:

If the member has cancelled, the reservations process is cancelled.

If the member has selected one of the available rooms, then the reservations agent guarantees the reservations and the process ends in success.

Figure 1 - BPD diagram example: Reserve a room in a private-members club

The controversy: Activity diagram or BPD?

Since activity diagrams (the subject of the previous BA ABCs blog) cover the same ground as BPMN BPDs, the question naturally arises, “Which diagram is ‘better’”? In fact, a controversy rages on this issue, with arguments made for and against each approach – so it’s worth exploring. One of the major advantages touted for the UML (the standard that governs activity diagrams) is that by providing a single standard across the lifecycle, translation errors are avoided. By this reasoning, it makes sense to use activity diagrams for both business process modeling and for modeling the logic of the software processes that automate them. On the other hand, the BPMN standard is often seen as the more natural candidate for the specific purpose of modeling business processes. In fact, the commonly accepted best practice is for BAs to use BPMN for this purpose (unless there is a compelling reason to use activity diagrams – such as the use of a UML tool across the project) and to use the UML for its other diagrams – primarily class diagrams. Let’s consider the arguments for and against each option to try to ferret out the truth.

Because the UML standard came out of the development world, its diagrams are thought to be code-oriented. But this is more an issue of perception than fact. In truth, the UML is a full-spectrum standard that supports both real-world and technical modeling. While it is certainly the case that there are features of activity diagrams that are technically oriented, the fact is that only a small subset of features should be used by the BA when communicating with business stakeholders – and this subset corresponds closely to commonly understood flowcharting symbols. (The same can also be said for BPMN.) I have a strong suspicion that the word ‘Business’ in the BPMN acronym has had as much impact as anything else in this perception of BPMN’s preferred status for business usage. But when you compare the aspects of the two alternatives that are actually used by the BA, feature by feature, there is in fact little difference between the two, as the next argument explains.

Argument #2: As a whole, BPMN diagrams are easier for business stakeholders to understand than activity diagrams

To get past the rhetoric, let’s compare the modeling elements most useful for BA purposes. Figures 2 and 3 show commonly used BPMN symbols along with their activity diagram counterparts. A quick glance indicates that it is hard to tell the two apart. When you look at these elements side by side you really have to wonder what all the fuss is about. There is one situation, in fact, that is expressed in a clearer manner (from a stakeholder’s perspective) in activity diagrams than on a BPMN BPD: parallel activities. Figure 4 compares the BPD and activity diagram symbols used to indicate two activities that may occur in parallel (meaning that they may occur in any order). I think most people would agree that the BPD symbol – a diamond with an enclosed ‘+’ sign, is much more cryptic than the straightforward parallel lines used for this purpose on activity diagrams.

Figure 2 - BPD flow objects (with UML equivalents)

Figure 3 - BPD connecting objects (with UML equivalents)

Figure 4 - BPD parallel fork (with UML equivalents)

Argument #3: BPMN includes special modeling elements that make it more suitable for business purposes than activity diagrams

Here I do believe there is some merit to the argument in favour of BPMN. One situation not well handled by activity diagrams is the Inclusive-OR. This is the logical construct used to model the common expression ‘and/or’ – as in: Do ‘A’ and/or ‘B’ and/or ‘C’ – depending on various conditions. Figure 5 illustrates the approaches used in the two standards. BPMN BPDs are clearly preferable to the mess of symbols required by activity diagrams. Another situation for which BPMN has a dedicated symbol relates to the handling of events. Figure 6 illustrates the difference between the two standards. BPMN relies on the placement of a circular event symbol to communicate to the reader the timing of a response to an event: an event symbol on an activity means that the event interrupts it whereas an event after an activity means that the activity first is completed and then the event is noted and responded to. Activity diagrams have a fairy simple alternative notation for this – but it may not be as readily obvious to the reader what is being conveyed.

In the ‘real world’, businesses interact with other businesses in limited ways, whereas organizational units within a single business have more complex interactions. In BPMN, this is modeled using pools and lanes. A business is represented as a pool and an organizational unit within the business is represented as a lane. Interactions between pools are limited to the passing of messages – effectively mirroring the way that businesses pass requests (messages) to each other while being unaware of each other’s internal processes. Figure 7 illustrates this approach. There is no formalism dedicated to this concept in activity diagrams, though the situation is fairly easily modeled by stipulating that businesses communicate by sending and receiving signals. Nevertheless, signals are not widely used for business process modeling and are less likely to be readily understood than pools by business stakeholders.

Figure 7 - BPMN B2B model using pools

Conclusion
For business process modeling, where all the players are within a single business, there is no compelling argument for either standard. While there are some small advantages to each standard, they tend to cancel each other out. (E.g., while BPMN handles the inclusive-or situation better, activity diagrams model parallel activities more clearly.) However, BPMN does have a clearer approach for modeling B2B interactions.

Final wordsThis discussion has focused entirely on the BA perspective. A separate set of arguments and comparisons could be made with respect to the suitability of the two alternatives for code generation. But that is a topic beyond the scope of this blog.

Thanks for notifying me of your article Howard. With respect to argument 4, I find UML's partitioning feature for activity diagrams is adequate when describing control flows across units or organizations. In fact, with the ability to have multi-dimensional partitioning, there are some activities that can be more easily described with UML partitioning than just regular pools and lanes in BPMN. The UML 2.3 Superstructure specification has a good overview of how partitioning can be leveraged.

You're welcome, Larimar - and thanks for the heads-up on multi-dimensional partitioning. If you have an example on-hand to post of how you've used it for this purpose (and the time to do this), I'm sure it would be of great interest to readers.

Abhirup - I am wondering if you meant Figure 5 (inclusive gateway) as opposed to Figure 6 (on interrupting events) - as Figure 5 is the case where I think there is a clearer advantage for BPMN. An example of Figure 5 would be the processing of an expense claim: if it includes travel, the full travel expenses are reimbursed and/or if it includes a meals claim, the amount is reimbursed up to $50 a day. BPMN is able to handle a situation like this simply, as shown in figure 5 (left diagram)- whereas a UML activity diagram requires a more complicated set of modeling elements.

As to Figure 6 (the one you asked about), it deals with event handling. The top set of diagrams (for BPD and for the UML activity diagram, respectively) deals with a situation where the process requires waiting for an event after a prior activity has completed. An example would be waiting to receive the results of a medical exam after the activity 'examine patient' has been completed. This type of case is handled well both by the UML and BPMN - as shown in the upper diagrams. The bottom set of diagrams in the figure refer to an event that interrupts an activity (rather than allowing it to complete first). It is here that I feel there is a slight advantage to BPMN. An example would be an activity to process a court case that is interrupted if the complainant drops the charges. Both the BPMN BPD (the left diagram) and the UML activity diagram (to the right) are simple enough - but BPMN is, in my experience, a little bit clearer. I find stakeholders don't quite get that a UML text label over a control flow denotes an event that interrupts the previous activity, whereas the BPMN representation (where the event symbol is attached to the activity it interrupts) is a little more readily understood. Perhaps the UML is just a bit too minimalist here.

re: Larimar's note on multi-dimensional partitions:I just had a look at your reference, Larimar. For those interested, the UML 2.3 superstrusture specification is available for free download at http://www.omg.org/spec/UML/2.3/.

Larimar referred to examples in the spec of a UML alternative to BPMN pools (used to model B2B interactions). The examples are on p. 353 and 354 of the spec. I think larimar is referring primarily to the nested partitions feature (first example) rather than multi-dimensional partitions (second example) - as a UML equivalent to pools.

The nested partition example depicts what looks like a BPMN Accounting Dept. swimlane and an Order Dept. in the same pool, and a Customer swimlane in its own pool. In fact - it's a UML activity diagram using nesting partitions. This feature and example approximate BPMN pools.

The multi-dimensional partition example has columns to represent activities performed in two cities (Seattle and Reno) - but then adds rows to represent the role (Order Processor, Accounting Clerk) within each city that performs the activity. If the columns represented different business organizations (rather than cities) then this layout could be used to described a B2B interaction - except that it would only model the situation well if both business organizations had the same internal roles.

Thanks for following up on my comment Howard and posting to the UML spec. I think the regular one dimensional pools would be sufficient to model a B2B interaction since the spec allows for pools and lanes, but the 2nd dimension is interesting if you have another consideration (such as location, time period, transmission mecahnism) that you want to model for clarity. I wouldn't want to over-use this feature, since as you mentioned the 2nd dimension must/should apply across all pools/lanes, but I could see it being helpful in certain scenarios.

I agree, Jarett. In fact, I just saw a great use of one of your examples of 2-dimensional: tables with participants as rows and time periods listed across the columns. It did a nice job of clarifying not only who would do each activity but when.