When I launched my course “Process Modeling with BPMN”, I discussed in this column why so many people beginning to “do” BPM were looking for training in modeling, and why that was especially needed for BPMN. Now, having delivered the training for five months, I have a better appreciation of BPMN’s strengths and limitations, a better understanding of what students really want, and what they really need to know about BPMN modeling. That learning is reflected in a major update of the 2-Day Training Course at BrainStorm DC (September 12-13) and New York (November 8-9) in conjunction with BPMInstitute.org. This column describes what I got right the first time, and where I’ve had to adjust.
One of the things I got right from the start is that BPMN’s extremely wide range of use and lack of built-in methodology is both a key strength and a weakness. Many students looking to “do” BPM are not thinking about automating their processes with a BPM suite. Modeling for them is essentially documenting the as-is process end to end, analyzing its shortcomings by visual inspection of the diagram, and making incremental improvements. BPMN can be used for that… and the training provides a methodology for doing so, leveraging the notation’s swimlanes to make cross-department handoffs – a key source of error and delay – stand out in the diagram, and collapsed subprocesses – linked to expanded detail on another sheet – for top-down models that can be shared and maintained.
But BPMN is most valuable when you go beyond simple documentation and analysis by inspection to quantitative analysis by simulation and executable process design. The reason is that the semantics of the notation’s core elements – activity, gateway, event – are precise enough that you can actually execute the model. That precision, and the rules that enforce it, can get in the way if all you’re trying to do is capture the as-is in a diagram. But if you view that capture as the first step along a path that ultimately goes to an improved executable implementation, then BPMN is the only way to go.
In fact, an increasing number of BPMS vendors have come to see that maintaining the BPMN diagram as a continuous “business view” of the evolving executable implementation is a central element of their BPM value proposition. This goes beyond the human-centric BPM pureplays like Savvion, Lombardi, and Appian, who embraced this idea from the start, but includes Tibco, Oracle, and webMethods (now SoftwareAG)… and I expect IBM and SAP to follow suit in the coming year. BPMN is the key to a new rapid iterative BPM implementation style in which business and IT collaborate continuously through the process lifecycle.
But this promise exacts a cost. BPMN has rules, and to make business-IT collaboration work, “business” has to learn them and follow them. The BPMN spec is often unhelpful, piling on needless complexity with multiple ways to draw the same process semantics and a bevy of exotic gateway and event types that are rarely used… and even more rarely needed. Addressing this reality – and the difficulty it poses for some business analysts – is a guiding principle of the updated training. We focus on the working subset of diagram patterns modelers really need, and which will suffice 90% of the time from simple as-is capture to full executable design.
Throughout the new training, we try to reinforce three central principles, or best practices, when process modeling with BPMN:
- Make important process detail visible in the diagram. The central purpose of modeling is shared understanding. BPMN is mostly a diagramming notation, but each diagram element also has attributes, many of which are only visible in property sheets or generated documentation. You may need these attributes for model interchange, simulation analysis, or executable code generation, but for shared understanding, only information surfaced in the diagram has business value.
That means adding labels everywhere, not just to activities but gateways, sequence flows, and events. Differentiating successful end states from unsuccessful ones by labeling end events adds to shared understanding. For advanced modelers, clarifying throw-catch semantics by paired labels (between thrower and catcher) adds to shared understanding. True, these labels might be redundant to hidden attributes required for simulation or execution, but in BPMN, the diagram is king.
- Make your diagrams valid. A model is not a doodle. In BPMN, each shape has defined process semantics, which depend on exactly how and where it is placed in the diagram. To make that work, BPMN defines rules, lots of them. To use BPMN effectively, especially if your ultimate goal is implementation, you need to learn the rules and apply them correctly. It’s not hard if you focus on the subset of BPMN that you really need, and reduce that to a few diagram patterns that everyone in the organization can learn.
The difference between a modeling tool and a simple drawing tool is that a modeling tool understands the rules, and can validate the diagram. The training includes graded hands-on exercises using itp commerce’s BPMN tool. In the original training, we did not explain or encourage use of its built-in validation function, since it would report errors when hidden attributes (required by the spec but useless for modelers – see #1 above) were missing. But after correcting so many student diagrams with basic validation errors, I now teach validation and encourage its use. I just say ignore the missing attribute errors, and in the next version of the itp commerce tool you’ll be able to selectively disable them.
- Make your diagrams hierarchical. Models are not wallpaper. Placing stickies on 30 feet of wall space is a fine way to capture an as-is end to end process, but “flat” models that you need to view by walking around a room do not provide sharability and maintainability, central qualities of a good process model. In the training we teach a top-down methodology, in which the end to end diagram can be drawn on one page using BPMN’s collapsed subprocess notation, exploding each subprocess at greater detail in another page of the diagram, and so on using as many levels as needed. These drilldown levels are hyperlinked in the modeling tool, so you can zoom in or out as needed, while the tool manages it all as a single model for simulation or code generation.
This sounds easy, but BPMN adds a bit of complexity. For example, sequence flows – the lines connecting process activities – cannot cross a subprocess boundary. Since you want the diagram to be valid at every level, this creates some gotchas, and we show you how to avoid them.
These three key principles drive the updated training. We teach advanced topics like error throw-catch, transaction compensation, and multi-pool processes – and even BPMN 1.1 changes like the new Signal event – but we’ve placed the major focus more squarely on learning the subset of diagram patterns you use all of the time, and applying the principles above. After five months of experience, this is what I’ve learned from the BPMN training.
