In March, Michael zur Muehlen of Stevens Institute of Technology and Jan Recker of Queensland University published an article based on their analysis of BPMN diagrams collected in the wild, as it were, from consultants and practitioners. As a survey of how BPMN is actually being used today, it is an interesting bit of research. But the authors’ interpretation of the results – beginning with the title of the article, “How Much BPMN Do You Need?” – was, in my view, incorrect, and a misreading of what BPMN actually represents. There was a lively debate on this topic on my BPMS Watch blog, but the basic issues are summarized here.
BPMN, which stands for Business Process Modeling Notation, is an OMG standard for the shapes and symbols used in process modeling diagrams, and their associated semantics. Despite the fact there is still no accepted model interchange format, BPMN has emerged as the important standard in BPM, particularly when the user’s intent is to follow modeling for documentation and analysis with an executable process implementation design. Because it binds the implementation, built out by IT, directly with the model, created by business, BPMN has turned out to be the key to realizing BPM’s promises of business-IT alignment and agility. For that reason, BPM Suites ranging from Lombardi, Appian, and Adobe on the human-centric end of the spectrum to Oracle, Vitria, and SoftwareAG on the integration-centric end are based today on BPMN. By the end of next year, any BPMS that is not BPMN-based will have to address the charge that it is “proprietary.”
Balancing the needs of business analysts, who demand simplicity and familiarity in the notation, with those of IT, who require expressive power and precise semantics, is a tough task, and BPMN has succeeded there where UML, IDEF and other notation standards have not. On the simplicity/familiarity side, BPMN is at first glance a swimlane-based flowchart, something every process modeler understands. There are only three shapes, one for each type of flow element in the diagram: rounded rectangle (activity) represents work performed in the process; diamond (gateway) represents flow branching or merging logic; circle (event) stands for a signal that something happened, and what to do if it occurs.
Except as indicators of where a process starts and ends, events are not so familiar to modelers, but to the process designer they are critical to model-driven implementation. Events describe how processes issue and respond to service requests, react to changes in business systems, communicate with other processes, and propagate exceptions internally. These are all things business cares about, but business has never had a way to model what should happen if the order is canceled or changed in flight, if submitted information is incomplete, or if a step is not completed by a deadline. BPMN now gives them the visual language, and an understandable – albeit unfamiliar – set of rules for applying it. At the same time, events give the process model the expressive power and precision IT needs so that the implementation can be layered on top of it instead of starting over in a different tool. Events are thus central to what BPMN is and why it is important as a standard.
Subprocesses are also a critical element of BPMN-ness. A subprocess is an activity that can be further decomposed as a process. In the diagram it can be drawn collapsed on one sheet as a single rectangle, and expanded in another sheet as a process, and this nesting can continue as many levels deep as you need to go. But the collapsed and expanded renderings of a subprocess are interpreted by BPMN as just two views of the same thing, not two different things. This allows the entire end-to-end process to be modeled as a single hierarchical entity, a concept fundamental to BPM as a management discipline yet missing from process execution language standards like BPEL.
Thus two features missing from familiar swimlane flowcharts are absolutely critical to BPMN’s role in business-empowered implementation: events, expressing exception handling and communications with external entities; and subprocesses, including the ability to toggle between collapsed and expanded views. Without these, you may as well use plain Visio or maybe a cocktail napkin to draw your process diagrams.
The study by zur Muehlen and Recker applies a different standard to the question of how much BPMN do you need: frequency of occurrence in diagrams collected in the wild. Based on that frequency, they assign the various shapes and symbols into four categories: core, extended core, specialist set, and overhead. The core plus extended core sets, representing all elements used in at least 25% of the diagrams studied, are just the elements familiar from the swimlane flowcharts of old: start and end events, tasks and sequence flow, pools and lanes, and exclusive gateways. But this is not all the BPMN you need; it’s just all the BPMN you already know.
In the specialist category, which I interpret as “the BPMN that somebody else in your company needs to know,” are subprocesses and solicited (wait-for) events. In the overhead category, which I interpret as “the BPMN that nobody uses,” are unsolicited events that trigger exception flows, such as a timeout or customer cancellation in flight, as well as any type of error event. Remove those and a business analyst can no longer describe exception handling in the model. It’s that fundamental.
Frequency of occurrence is the wrong standard to use for recommending, as zur Muehlen and Recker do, how much BPMN practitioners need to learn, how much tool vendors need to support, or how much OMG needs to think about. The reason is that the real essence of BPMN, the part that makes it so useful, is the part that goes beyond the already familiar. That means it requires a bit of education and training, a bit of methodology and best practices, and a bit of discipline, to use BPMN effectively. We offer that in our BPMInstitute.org training, and numerous other sources of education are available as well.
It’s a learning curve, and the larger BPM community is just beginning to climb it. If zur Muehlen and Recker had surveyed the models of students who took our training, I’m confident they would have found a different result.
