Following the Rules

Fortunately I was on vacation last month when Jim Sinur launched his fatuous "Burn Baby Burn" bomb, the one about how BPMN is too hard for Gartner clients. In the ensuing discussion, cooler heads mostly walked Jim back off the ledge, but the back-and-forth still did not get to the heart of the real problem, at least as I have experienced it.

In my view, it's not really about "business users" or what exactly is a business user. Creating good BPMN is often more difficult for architects and developers than for business people. It has nothing to do with BPMN 2.0 vs BPMN 1.x. Almost all of the differences between them are below the waterline, in hidden XML details, not in what prints in the diagram. And it's not about the unwieldy BPMN vocabulary of event and gateway types. As others have pointed out, we already have a limited working set of shapes and symbols in the Descriptive process modeling subclass, and tools like IBM Lombardi Blueprint have an even more limited palette than that. Trust me, you can create bad BPMN with nothing more than tasks, XOR gateways, and None start and end events.

I say with some confidence that I have probably looked at more bad BPMN than anyone on the planet. And I don't say it proudly, because these are certification exercises submitted to me by students following two days of intensive BPMN training delivered by me personally. While we get some "ordinary business users" in the training, the majority nowadays are business process analysts, business architects, enterprise architects, BPM consultants, and BPM developers. Most of them are not new to process modeling, either.

The problem with BPMN is it demands you follow the rules. When we used to draw process diagrams in plain Visio or PowerPoint, there were no rules. Modelers made up their own rules. They knew the meaning, more or less, or boxes and arrows and diamonds, and close was usually good enough. But in that kind of modeling, the diagram was rarely meant to be a standalone artifact. It was just a vague depiction of a process detailed in an accompanying 100-page book of documentation or business requirements.

On the other hand, BPMN lets you create diagrams that stand on their own, describing the activity flow precisely and compactly, what comes before what, what activities are conditional, what activities are concurrent, the logic of taking this path or that, how the process starts and the various states in which it can end, and how the process touches the external environment... all without resorting to the 100 pages of documentation. In fact, if your process diagram doesn't reveal all those things, I call it bad BPMN.

To create good BPMN, you need to follow the rules. It's not really hard to do, and it's a readily learnable skill. Still, for some experienced modelers that's a problem, since they've already made up their own rules and prefer to follow those. The real problem is knowing what the rules are!

First, the BPMN spec does not enumerate its rules. They are in there, but buried in the narrative of a 516-page specification in combination with some UML class diagrams and an XML schema. And sometimes those three sources don't precisely agree with each other. There should be an appendix that simply lists the rules, in plain English and in a way that is easily computable by any tool. But there isn't.

Real BPMN tools, like Process Modeler for Visio from itp commerce, or native Visio Premium 2010 from Microsoft, include a validation function that tests a model against that tool's interpretation of the BPMN spec. That's a good thing, and I don't want to minimize the value of that feature. But they don't go far enough. Those rules just enforce the basic semantics of the shapes and symbols, for example the difference between sequence flow and message flow, what can legally connect to what. Your model can have zero validation errors in the tool and still be, by anyone's definition, bad BPMN.

Good BPMN goes beyond the rules of the spec, into the realm of "method and style." What makes good BPMN, I suppose, depends on your purpose. My purpose is creating non-executable models in which the diagrams stand on their own, clear and complete, shareable across the business (to those that understand the rules) and between business and IT. So I have developed an expanded set of BPMN rules, encompassing both those of the spec and the method and style domain, and that's mostly what my BPMN training is about.

My problem, like that of the BPMN spec itself, is that those rules are not listed in one place. In the training they are mostly collected in two or three places, and the key ones repeated throughout... but really they should be in a simple list, in one place, formatted for easy reference. OK, that's coming.

And, like the rules of the spec, they should be supported by a tool. That's coming too, hopefully this week. Users will upload models in XML from either itp commerce Process Modeler or Microsoft Visio Premium 2010, and the tool will list both the spec errors and the "style" errors. Beyond students in my training, I haven't decided how to expose the tool to the general public, but if you are interested in trying it out, contact me and we'll see what we can do.

This is a good place to stop. Next time I'll provide the list of BPMN rules.