BPMN Level 3 Method and Style - First Thoughts

Most of the changes between BPMN 1.2 and BPMN 2.0 have to do with extending it from a diagramming notation to a language for executable process design. Both my book BPMN Method and Style and the training that goes along with it deal with non-executable models, what I call Levels 1 and 2. Level 1 is limited to a basic working set of shapes and symbols familiar to business - similar to the new Descriptive conformance class of BPMN 2.0 - and useful for process documentation and qualitative analysis. Level 2 adds support for some additional elements, most notably intermediate events - the palette is similar to the Analytical conformance class of BPMN 2.0 - and represents the common process language shared by business and IT. It describes in precise detail the activity flow of a business process, but by itself it is not executable. Executable BPMN is what I call Level 3.

Levels 1 and 2 deal with shapes and symbols in the diagram. Level 3 deals with stuff you don't see, XML underneath the activities, gateways, and events that make them executable on a BPMN engine: things like variables, messages, data mappings, and condition expressions. I talked a bit about it in the book, but just a little because no tools for Level 3 BPMN existed. But now one does... Oracle BPM11gR1.

I've spent a few days with Oracle BPM11gR1, and it's got my juices going about developing some Level 3 training. Since the hard part of my training approach has been getting "method and style" alignment between Level 1 and Level 2, I was interested to see if Level 3 could be aligned with them as well. A Level 2 diagram that can be shared effectively by business and IT should ideally work as the starting point for Level 3, but I wasn't sure if it would. The answer probably varies from one BPMS to the next, but my first impression is that with Oracle, it does!

What I am trying to do is define a "cookbook" approach that allows business analysts to create executable processes using BPMN, starting from a Level 2 model as described in my book and current training. I'm striving for simplicity and consistency rather than elegance. Key elements of my approach include hierarchical modeling using subprocesses, explicit depiction of "end states" in the diagram, and top-down traceability through labeling.

Hierarchical modeling is a little clumsy in the initial release of Oracle BPM11g. A subprocess in BPMN can be drawn either collapsed as a single activity or expanded into a process, and you can toggle between those views, as they both reference the same semantic elements in the model. Hierarchical modeling works best when the expanded view (child level) is drawn on a separate diagram hyperlinked to the collapsed shape in the parent level diagram. But you can also show both levels in the same diagram by enlarging the rectangle enclosing the expanded subprocess and reflowing the rest of the parent level around it. Oracle only implements the latter way, and when you collapse the subprocess again the tool leaves the reflowed diagram unchanged... but with lots of white space where the enlarged expanded subprocess used to be. In real-world diagrams, my methodology uses several levels of nesting, so the diagrams in Oracle would get kind of ugly. I suspect Oracle will allow hyperlinking to the child level expansion when they add Call Activity (fka reusable subprocess) in a near-term patch release. At least I hope so...

The concept of end state is key to my methodology. It's not in the BPMN spec, but it's an important concept nonetheless. From a business standpoint, an activity can complete in various end states. Typically one represents the "success" end state (although there may be more than one) with possibly one or more "exception" end states. In a subprocess I teach students to use a separate end event for each distinct end state, and to label them to indicate the end state, such as Approved and Rejected. When the process flow following the subprocess depends on the end state, a gateway labeled as a yes/no question makes the logic perfectly clear. For example, a gateway labeled Approved? is interpreted to mean take the Yes path if the preceding subprocess reached the end event labeled Approved. Through conventions like these, hierarchical models can be traced top down without ambiguity.

Oracle BPM11g supports end states natively for most activity types. Subprocesses have output arguments that map to data objects (process variables) which can be tested by gateways. Human tasks return a string variable called outcome that represents the end state, and business rule tasks do something similar. Subprocesses can also throw a user-defined business exception to the boundary, which can also represent the end state. These constructs make translating Level 2 flow logic into executable BPMN Level 3 quite straightforward.

There is a lot more to say about Oracle BPM 11g, and as I have more time to play with it I'm sure I'll be doing just that.