BPMN: The Evolution of Method and Style
Blog: Method & Style (Bruce Silver)
It’s hard to believe I’ve been doing BPMN Method and Style training for 10 years. With the introduction of a major new version from one of my tool providers, and plans to bring on another tool, I’m now at work on the 7th – and hopefully last – version of the training content. And it is causing me to reflect on how BPMN 2.0 is actually used today, as opposed to the notions of its creators back in 2009, and what that means for BPMN training.
If I could summarize the theme of this evolution in two words, it would be simplification and clarification. As its many critics have noted over the years, BPMN is more complicated than it needs to be. It offers different ways to describe the same behavior, where just one would suffice. Method and Style will teach just one way. At the same time, the BPMN spec does a terrible job of explaining the meaning of its most fundamental concepts, like activity and process. BPMN assumes a very narrow meaning for both, having to do with being performed repeatedly on instances, which is at odds with the meaning of those terms in BPM more broadly. That means, for example, that in a BPMN process, the instance of each activity it contains must have 1:1 correspondence with the process instance, so sometimes a single business process must be modeled as multiple BPMN processes working in concert. Programmers creating executable processes understand that, but most process modelers do not. BPMN Method and Style spends time on this concept, how the process start event defines the instance, and how to handle things like batching.
Even so, there are many business processes that cannot be described by BPMN at all, including “management processes” such as Manage X or Monitor Y or Maintain Z. They are performed, in a sense, continuously, not repeatedly on instances. Another class of processes where BPMN doesn’t work we call case management. BPMN assumes that all instances follow some activity flow path specified at design time, and that is not always the case. BPMN’s critics have harped on this point for years. But we now have a standard, CMMN, for those, and on the BPMN side we should just be more vocal in our admission that, yes, there are some kinds of processes where BPMN is not the right description language.
Fortunately, there are very many processes where BPMN is the right language, and it continues to be widely used. Its wide adoption by business users derives from its outward similarity to traditional swimlane flowcharts, but that familiarity is also at the root of its weakness: Unlike flowcharts, BPMN models describe process behavior precisely, the meaning determined by the BPMN spec, but that actual meaning may not reflect the modeler’s intent. Sometimes the model violates some rule from the spec, and what does it mean in that case? A much bigger problem, in practice, is that the meaning of a BPMN model, even one that violates no rule of the spec, is unclear to anyone who does not already know how the process works. This is where Method and Style comes in.
Even though for the vast majority of BPMN users the purpose of the model is to communicate the process logic clearly and completely through diagrams, that was not actually the goal of the BPMN 2.0 technical committee back in 2009. Their goal was to replace BPEL – a process execution language having no standard notation – with a new BPMN version that would unify BPMN’s graphical notation with precise execution semantics. As a result, most of what BPMN 2.0 specifies is “below the waterline,” in XML that has no diagrammatic representation. The committee succeeded in the sense that BPEL is largely gone and most process automation engines are based on BPMN 2.0, but almost none of that below-the-waterline XML from the spec is used. An unfortunate by-product of that focus is that showing in the diagram the graphical details that actually make the notation useful, such as event triggers and message flows, was made optional in the spec. Of course those details would exist in the XML – otherwise a process engine wouldn’t work – but clear visual communication was never a major concern of the committee.
The Style part of BPMN Method and Style comes down to additional rules, on top of those of the spec, intended to make the meaning of the process logic clearly evident from the printed diagrams alone. A general principle is that if BPMN provides notation to indicate some detail of the process behavior, it must be used – even though the spec says it’s optional. And there are rules about how shapes are labeled, including label-matching between shapes in different process levels. These style rules are incorporated in the model validation from the tool vendors used in the training – itp commerce, Signavio, and soon Trisotech – and that validation has proved to not only improve model quality but teach users good BPMN style.
The Method part deals with a more difficult problem, the fact that the information gathered from stakeholders is not, in its raw form, reducible to “good BPMN,” or even properly structured BPMN in which the instance of each activity is aligned with the process instance. Creating “good BPMN” requires reorganizing that information, and the Method provides a systematic approach to doing that. It is difficult for modelers for two reasons: First, it asks the modeler to think about the process top-down and somewhat abstractly, whereas the information gathering is invariably bottom-up and concrete. Second, it’s just an inherently difficult thing to do.
The Method asks the modeler to sort all actions described by the stakeholders into a small number of buckets that will become top-level activities in the BPMN. That means the instance of those actions must have 1:1 correspondence with the process instance. If they do not, they go into special buckets off to the side; they will go into other BPMN processes. Then, for each top-level activity, when all its actions are complete, the Method asks, “Where does the process instance go next?” The answer can only be one of the other buckets or one of the process end states, and if there is more than one possibility, the modeler must enumerate the activity end states. A top-level activity with three possible next steps must be followed in the BPMN by a gateway with three gates, one per end state. Turning this list of activities and end states into BPMN is a purely mechanical exercise. It could be automated in software, and itp commerce has actually done this in a wizard that generates good BPMN – including lanes, message flows, and proper labeling throughout – all from a structured interview.
For managers of process modeling teams, the real benefit of the Method and Style approach is it gets everyone in the team on the same page, so to speak, because the process models have a consistent look and feel. Given the same set of facts from the stakeholders, all modelers should create more or less the same BPMN model. And that means that any team member can understand, in precise detail, the meaning of another team member’s model, simply from the printed diagrams. This aspect of BPMN Method and Style has been there from the beginning, and is at its core.
But I mentioned at the beginning that I continue to make changes in order to simplify the training. When BPMN 2.0 was new, I was more concerned about showing all the different ways to model something. Now I see that as unimportant. One way is usually sufficient.
Throwing message events have been a thorny issue. In executable BPMN, a message is a system-to-system communication sent or received by the process engine, but in non-executable models – the focus of our training – we use message flows to represent any one-way communication between an actor in the process and something outside the process. For inbound messages that works well, but outbound messages are harder. Can a throwing message event represent a message sent by an actor in the process? Lanes, for example, apply only to activities, not gateways or events, so does the lane of a Message end event necessarily indicate the sender? Previously the training made frequent use of Message end events to return final status, but going forward I plan to use activities to send those messages, since that aligns more closely with modeler expectations.
Parallel split gateways are often unnecessary, because two sequence flows out of an activity means the same thing. In fact, early drafts of BPMN 2.0 expressed a preference for omitting parallel gateways in that case. But my students have expressed a clear preference for using the gateway, so going forward I won’t be teaching multiple outgoing sequence flows. Maybe a style rule warning against it would even be appropriate. I’ve already dropped conditional sequence flows. Gateways require one more node in the diagram, but they are more intuitive.
I’m still on the fence about a couple issues, and they would represent a more significant change. I’m interested in reader comments on these:
- Event gateway. While it can be used more broadly, the main use of event gateway is to put a deadline on waiting for a message. But there is another way to model that – a Receive task with timer boundary event – that students generally find more intuitive. Should I stop teaching event gateway? (I can already hear my students shouting “YES!”)
- Error event and Error throw-catch. An Error event represents an exception occurring inside an activity. In my book I recommended using Error events for techical exceptions and gateways to test for ordinary business exceptions, and that still makes sense for executable BPMN. But the training is about non-executable BPMN, and there I have been teaching that anything you can do with Error events you could do just as well with gateways. So should I stop teaching Error events? It would make it simpler.
I’m a little nervous about implementing those changes, but they are both consistent with the goal of making process modeling with BPMN as simple and mechanical as possible. For any common process behavior, there should be exactly one way to model it. The goal is reducing BPMN to its simplest and most intuitive form.
For more information on BPMN Method and Style training, click here. If you want to get your whole team on the same page, our next live-online class is July 18-20 from 11am-4pm ET. Click here to register. Or if you want the web/on-demand training, click here. Our training includes loads of in-class exercises with a BPMN tool plus post-class certification at no extra cost. You can’t learn BPMN from a book or lecture alone. You must be hands-on with a tool doing real exercises.
The post BPMN: The Evolution of Method and Style appeared first on Method and Style.
Leave a Comment
You must be logged in to post a comment.
