From some of the recent comments on my posts, I see that I haven't done a good job of explaining what exactly I mean by my "method and style" approach to BPMN. Also, that approach has gone through a few stages of evolution. So this is a good opportunity to both explain it to BPMS Watch readers and "think out loud" about how to reflect it in the next iteration of my training.
Over time, the approach has gradually evolved from a set of principles, patterns, and best practices toward a prescriptive, quasi-mechanical cookbook for creating models that are clear, complete, and consistent across the business. That might seem to many like the wrong direction, but I have found, after four years of doing BPMN training and grading student exercises, that the biggest impediment to creating good BPMN is not understanding the semantics of the shapes and symbols. The difficulty is in structuring models so the process logic is self-evident from the diagram itself, and remembering (and applying) BPMN's rules.
The "method" part of my approach is a recipe for creating the structure in a consistent way. The "style" part is about the rules, not just the technical rules from the spec, but additional rules that enforce the labeling conventions of the method. An important change to the next iteration of training is something I've discussed in recent posts on this site: shifting the style part from "tips and best practices" to a more matter-of-fact, "Here is the list of rules and some tools that validate your models against them. Use the tools and follow the rules."
Why is this important? All of the recent to-do from Jim Sinur and others about how business people don't want to be constrained by no stinkin' rules is just one side of the story. The people who come to me for training have a different view. They say, "We have lots of groups in the company doing process modeling. But everyone does it their own way, and the models can't be shared or integrated with each other. So a lot of our investment in process modeling so far can't really be leveraged."
That's the problem that BPMN is trying to address and that I am trying to address with my approach to it. If diagram consistency and shareability are not your concerns, then maybe BPMN is not for you. Informal flowcharting with boxes and arrows may be all you need.
My method creates process models with a hierarchical structure. That means there is a single top-level "page" of the model that contains a high-level view of the end-to-end process, including how it starts, its various possible end states, and its touchpoints (BPMN calls it "collaboration") with the external environment - requester, service providers, and other internal processes. On a letter/A4 page, that leaves room for about 5-7 activities, represented as collapsed subprocesses. Those aren't meant as sample activities, with others in between to be added later on, but rather the major steps or phases of the process. They are the buckets into which details will be added in child-level diagrams.
The value of the hierarchical style is that you can visually understand the end-to-end process (and its touchpoints with the global environment) on one page, and zoom in and out to see detail at any level... all within the confines of a single semantic model. It reflects what could be called an "architectural" approach to process modeling, the way business architects and enterprise architects like to think about it. In contrast, the traditional approach, creating separate high-level and detailed models, requires continual manual synchronization as the model(s) evolve over time.
I favor the hierarchical/architectural approach, but I have come to see that some groups don't really care that much about the "end-to-end," i.e., customer-facing, process scope, or cluttering up their diagrams with message flows to requesters, service providers, and other processes, or having to drill down to child pages to see process details. (They do have a strange passion for swimlanes, however, a somewhat flawed element in the BPMN palette.) Often these folks come from BPM's well-established process improvement tradition, sometimes with a Lean or Six Sigma flavor. They may favor flat, single-level diagrams, even when they stretch over pages and pages. with a common set of swimlanes stretching over all of them.
For the next training iteration, I am thinking about whether an alternative form of the method could be fashioned for this style of modeling. BPMN's expanded subprocess shape tries to bridge the gap between the hierarchical and flat styles, and a few tools let you toggle back and forth between them, but swimlanes are not allowed in these shapes. I am also thinking about how the building blocks identified in business process architecture (sometimes called Level 0, 1, and 2 processes) relate to the top-level subprocesses in my hierarchical BPMN models, and a clearer statement of principles about how to "factor" end-to-end process models.
Another important method and style concept that will receive even sharper focus in the next training iteration is the notion of end state. You can look through the entire BPMN spec and not see this phrase mentioned once. But I believe it is critical to BPMN diagrams that stand on their own. For many process activities you can ask the question, how did this activity end? Did it complete successfully or in some exception end state? For example, was approval denied, or was there some problem such as incomplete data or an ordered item was out of stock? Was the activity aborted before normal completion, possibly for taking too long or perhaps interrupted by a message from outside?
In the method, a gateway following an activity is interpreted as testing the normal-completion end state of that activity. If it ended OK, take this path; otherwise take this other path. Abnormal completion end states and their continuation paths are represented by boundary events and exception flows. While the end states of a task are implicit, the method says make the end states of a subprocess explicit, in the form of distinct end events. A style rule says that if a subprocess is followed by a yes/no gateway - that is, a gateway labeled as a question, with gates labeled 'yes' and 'no' - you should label one end event of the subprocess to match the gateway label. In other words, if the gateway is labeled 'OK?', one end event of the subprocess should be labeled 'OK'.
This and other style rules assist in what I call top-down traceability. That means that someone unfamiliar with you or your process, or even your terminology, can trace your process logic in detail by labeling conventions that provide semantic links between parent and child-level diagrams.
BPMN provides an endless supply of XML elements underneath each shape in the diagram, into which you can stuff as much detail or documentation as you want, but the method and style approach ignores them. If some information doesn't appear in the diagram itself, it doesn't count. One thing you cannot show in the diagram is the data model (except in a very crude way using dataObject and dataStore), and so you cannot really provide explicit data expressions on gateways, or other similar technical details. All you really have to work with are labels: labels on events, on gateways, on sequence flows, on message flows, etc. In fact, in the BPMN 2.0 Descriptive and Analytic process modeling conformance classes - the subsets of BPMN intended for model portability - the only XML attributes supported for each diagram shape are the unique id (needed to hold the model structure together) and its name, i.e. label. That's it.
The "style" rules, listed in a previous post, are mostly about proper labeling to ensure top-down traceability of the diagram. So you don't have to memorize them, I've developed an online tool that looks at your model and lists the violations. As I mentioned previously, I am considering how and when to make that available to the public.
While I think it has great value on its own, the method and style approach to BPMN is even more valuable when integrated into BPM project methodologies. Work is progressing on multiple fronts there:
- Robert Shapiro is developing a process performance optimizer that supports method-and-style conventions such as matching subprocess end states to gateway paths. Unlike typical simulation engines, which are focused on optimizing resource allocation to reduce backlogs at process bottlenecks, this tool is aimed at the much more common structural analysis done in the process improvement world.
- Shelley Sweet of I-4 Process, an excellent process improvement consultant out of the Lean/Six Sigma tradition, is integrating her process modeling, analysis, and design training and consulting to use BPMN method and style conventions and tools (hopefully Robert's tool as well).
- Larry Goldberg of KPI, author of The Decision Model, a groundbreaking approach to creating maintainable decision logic (business rules). incorporates BPMN method and style in his KPI methodology, with an emphasis on improving business requirements through these structured models.