What Is Method and Style?

This year marks the fifteenth anniversary of Method and Style, and over the years it has held up well. Method and Style is a set of conventions layered on top of the BPMN standard – and, more recently, DMN and CMMN as well – intended to make the meaning of the model clear and complete from the printed diagrams alone. As a standard based on diagrams, BPMN promises “What you see is what you get,” but the task force developing the spec actually was working toward a slightly different goal: “What you model is what you execute.” And what you see is definitely not everything that you model. Method and Style tries to close that gap.

I still hear from managers, “We spend all this money on process mapping projects, but in the end the only ones who understand the diagrams are the people who created them.” At the root of this problem is the fact that the basic look of BPMN is based on traditional swimlane flowcharts, with boxes and arrows, long preceding BPMN but without any common precise meaning to the shapes. The challenge for the BPMN 2.0 task force was to provide the shapes precise meanings and operational behavior so that, in fact, what you model with those shapes is indeed what you execute, and execution works the same way in any compliant tool.

It was purely by accident that in 2009 I found myself on the IBM-SAP-Oracle team competing to draft the BPMN 2.0 spec. I had been doing training on BPMN 1.x for a couple years by then and had a good idea how modelers used the diagrams and the kinds of mistakes they made. My students were not interested in automating their processes, simply describing them clearly for documentation, analysis, and improvement. But the other team members had little interest in that. They were singularly focused on the execution details, most of which were invisible in the diagrams. They desperately needed BPMN diagrams to be executable in order to win business support for their major IT push to service-oriented architecture (SOA). Use of the diagrams for purely descriptive modeling was of no interest. And this stance was evident in the resulting spec.

For example, while the spec provides various icons and symbols to clarify the meaning of activities, their use is optional. And not only is there no guidance for labeling of the various diagram elements, there is no requirement to provide labels at all! That is why, when you validate the diagram below against the rules of the spec, you get no errors:

But what does that diagram mean? Basically it means nothing at all. Contrast that with the same diagram adorned with the optional icons, markers, and labels:

Now the diagram has concrete meaning. The style part of Method and Style is based on rules that require the icons and labels, sometimes with a particular format, and assign specific meanings to them. But to get modelers to pay attention to those rules, it’s best when they are validated in the BPMN tool itself. The Style Validation feature of Trisotech Workflow Modeler, for example, provides this. When you test the first diagram with Style Validation, you see a list of errors:

The error messages here just say that labels are required, but Method and Style actually prescribes their format. A Message start event label, for example, should be labeled “Receive [message flow name]”, and the message flow must be drawn and labeled (a noun, the name of the message). End events, if there are more than one, should be labeled Noun-adjective to indicate the end state of the process instance, i.e., how did it end? With Message start events, the process instance is indicated by the start message label, here Request, so the end event labels indicate how that Request was fulfilled, successfully or otherwise.

Complicating matters is the fact that process data and the data expressions executed by the process engine, while they are actually what controls execution behavior, are not shown in the diagram. Process variables in the form of data objects do have diagram shapes, but they are used only in executable models. The reason is that BPMN does not standardize the language of process data and expressions. Most executable BPMN tools use Java, thus outside the understanding of business users. The challenge for Method and Style, then, is to imply the data suggested by the flow, and use that implied data to label the diagrams.

Here Method and Style uses the concept of activity end states, meaning how did the activity instance end? I’ve mentioned already process end states, indicated by labeled end events. The end states of a subprocess are similarly indicated by labeled end events. Because you cannot look inside a task, there are no labeled shapes to indicate its end states. Instead they are implied by the gateway that immediately follows the task. Enumerating the end states of an activity would seem to be completely subjective, but Method and Style prescribes the way: Each activity end state corresponds to a distinct next step – activity or event – following completion of the activity. If there are two distinct next steps, that implies two activity end states, named by the gate labels leading to those respective next steps. For example, in the diagram above, the task Validate request has two possible next steps, the task Handle request and the end event Request rejected. That means Validate request must be followed by an XOR gateway with two gates, appropriately labeled to indicate the task end state leading to each possible next step. If Validate request were instead a subprocess, Method and Style would require the child level diagram to have exactly two end events, labeled to match the parent level gates, “Valid” and “Invalid”. And this would be checked by Style Validation.

Another problem of the BPMN 2.0 spec is the vocabulary of shapes and symbols is too large. Like any work of a committee, the spec contains some elements of little utility. Moreover, some elements make sense only in executable models and should not be used in descriptive models. Method and Style pares down the vocabulary. For example, a Script task is automated logic executed on the process engine, while a Service task is automated by some other engine. Similarly, a User task is a human task assigned and monitored by the process engine, while a Manual task is a human task invisible to the process engine. Since these distinctions are meaningless in descriptive modeling, where there is no process engine, Method and Style does not use Script or Manual tasks. We also try to limit events to Message, Timer, and Error. There is really little need for the others in descriptive BPMN, and students who use them usually do so incorrectly. Simplifying the BPMN vocabulary leads to better models.

All of this relates to the style part of Method and Style. There is also a method piece, although it is used less often. The method is a procedure for creating a properly structured model by top-down decomposition, as opposed to the normal practice of stringing together activities noted in the process discovery sessions. It’s hard for students, because most are used to thinking concretely from the bottom up rather than abstractly from the top down. In the method, you start by identifying the process instance, when it starts and the ways it possibly ends. That nails down the process start and end events. Then you divide everything that happens in the process into a handful of subprocesses. Just name them at this point. Now for each subprocess, think of where the instance could possibly go next, after the subprocess completes. It can only be one of the other subprocesses or one of the end events. That list of possible next steps determines the subprocess end states, and if there is more than one possible next step, the gates of a gateway following the subprocess. Now you have your top-level diagram. I like to do this without lanes, which only complicate the drawing at this stage. You can always add lanes at the end.

Next, create the child level of each subprocess. Already you know its end states. And you can continue this decomposition to further child levels. The method does not include adding events, which you can add at the end, but it results in a properly structured BPMN model, always a good starting point.

So what’s the benefit of all these new rules and methodology? They are not part of the spec, that’s true. But if you get your whole team – actually, all the stakeholders in your process models – to understand and use them, an amazing thing happens: The meaning of the process model is understood by all, simply from the printed diagram alone! In the descriptive modeling world, that is a huge win. Otherwise, it rarely happens.

OK, so how do you learn to do this? One way is my book BPMN Quick and Easy. It’s fairly short and to the point. My earlier book BPMN Method and Style is more comprehensive, but it doesn’t pare down the vocabulary as much as I’ve learned to do after many years of BPMN training. A better way is my BPMN Method and Style training. It’s better because it’s hands-on with a great BPMN tool, Trisotech Workflow Modeler, which has the Style Validation built in. Students get 60-day use of the tool for use in the many in-class exercises as well as the post-class certification, in which students must create a model containing certain required elements and submit it for my review. If there are errors – and usually there are some – the student must fix and resubmit. It’s actually in this cycle of fixing and resubmitting that the weak parts of the student’s understanding come to light and the student has that Aha! moment. It is satisfying for student and teacher alike. There is a lot more information on Method and Style and the training on my website methodandstyle.com. Check it out!