When you get started in BPM, the first step invariably is documenting your current, or as-is, process. You can gather the facts from process participants and process owners in a variety of ways – in a group, putting yellow stickies on the wall, or in separate interviews. But eventually you face the challenge of reducing that collected knowledge into a structured, semantically precise yet intuitively understandable, diagram – a process model.
The majority of process “models” in the wild are simply Visio diagrams, applying shapes and lines as the individual modeler sees fit. That simplifies the task for the individual modeler, but diagrams without precise process semantics tied to a structured notation have limited value. They are not immediately understood by others without a detailed accompanying narrative, making it harder to achieve the number one goal of process modeling, which is shared understanding of how the process works. Moreover, these unstructured models are merely descriptive, and cannot be used to project process performance using simulation analysis. For that you need both a structured notation and a methodology to use it correctly. Nor can they be used to fulfill BPM’s “Third Wave” promise, that a model of a new and improved process can be used to actually generate an executable implementation.
All right, you accept that your old seat-of-the-pants Visio diagrams are less than optimal as process models, so you look for a “real” modeling tool. You quickly find that there are a multitude of them available, each with its own diagramming notation, usually some variant of a flowchart or swimlane diagram. These tools tend to fall into one of two categories. Full business process analysis (BPA) tools, such as IDS Scheer ARIS or ProForma’s ProVision, make use of a welter of interlinked models, of which the diagrammatic process model is just one. A variant of this category, blending into the more IT-oriented enterprise architecture toolset – tools such as Casewise Corporate Modeler or Telelogic System Architect – also makes the process diagram just a small piece of a much larger modeling effort.
Products in this category are rich and complex, and cost thousands of dollars per seat. They do more than just descriptive modeling, but typically include KPI definition and simulation analysis (sometimes linked to actual business activity monitoring), and even generation of skeleton executable BPEL from the model. They are generally offered with extensive training, on both the tool and its accompanying methodology.
The other category is typified by the modeling tools built into most BPM Suites. They are much more stripped down and focus attention on a single model, represented by the process diagram. They are essentially “free” – although with most of them, you have to buy the BPMS first! They typically require no training, and have no real methodology for how to use them properly from a business perspective. Most of them provide simulation analysis as well as generation of executable artifacts used in the BPMS design environment. Because they are tied to the inner workings of the BPMS process engine and its associated execution language, they tend to omit notational patterns that the process engine does not support and add non-standard features of the BPMS environment. Thus even those tools that claim to be based on modeling standards usually implement just a subset of the standard plus some non-standard elements.
Today the term “process modeling standard” has come to mean the Business Process Modeling Notation from OMG. Unlike the BPA tools, BPMN concentrates process understanding in a single model, the business process diagram. To me, that’s much more effective for shared understanding than 12 interlinked models. Like most structured modeling notations, BPMN is based on traditional swimlane diagrams, but adds an innovative twist enabled by today’s IT system architectures: the ability to respond to business events. An event is a signal from some external system or process that something has occurred, or possibly a signal sent by the process to another process or even to another part of the same process. While process flow in BPMN is mostly based on the traditional flowcharting paradigm – after Activity A ends, start Activity B – it also includes a symbol for events. The event symbol can be used in many ways: pause and wait for a particular event, or interrupt an ongoing activity if the event occurs, or both signal and respond to an error or timeout.
In modern service-oriented architecture, events – in the form of SOAP messages – are the way business services communicate with each other. By including events as a standard feature of business processes, BPMN allows processes to interact more flexibly with the external environment, and react in real time to exception conditions. BPMN-based process models thus allow the business analyst to describe behavior unavailable with traditional flowcharting, such as how to handle a change to an order “in flight” – when is that change event valid or invalid, and how is it handled, including the semantic precision required to do simulation analysis.
Unfortunately, events are the part of BPMN that most modeling tools leave out. BPA vendors say they’re too complex for business analysts to understand. (Probably they would also break those vendors’ simulation engines.) BPMS offerings, particularly those coming from a workflow heritage, also may have limited engine support for events, so they too tend to leave them out of the modeling tool. A few have stepped up to the challenge – Appian, Lombardi, and Cordys, in particular. Savvion and Tibco have added partial event support to their downloadable BPMN tools, as well.
An important downside of BPMN is that it has strict rules but no standard methodology. Each tool vendor tends to ignore the rules and assume its own methodology, based on the subset of BPMN that it implements. The BPA vendors just support a limited piece of BPMN, and the BPMS vendors’ methodology emphasizes building the executable implementation, which is beyond where most people starting out in BPM want to go, at least immediately. That means that while BPMN takes a quantum leap beyond traditional process modeling, business analysts are left in the dark as to how to use it correctly and effectively.
I see huge interest among the BPM community in process modeling with BPMN. The range of available tools is large and continually increasing, and they are much less expensive than full BPA. But there is also a dearth of educational material on how to use it, including both adherence to the rules defined in the BPMN specification – something the tool vendors themselves don’t understand very well – and a best practices methodology for mapping the yellow stickies on the wall into the notation. That’s why I’ve been developing a training course on just this subject, which will be offered through BPM Institute as well as through other channels in 2007.
That’s why I’ve been developing a training course on just this subject, which will be offered through BPM Institute as well as through other channels in 2007.
For that training I wanted to find a tool with the following qualities: a) supports full BPMN, including events and business transactions; b) provides simulation analysis, including support for events; c) independent of a particular vendor’s BPMS; and d) free, at least for use in the training. I found one in Process Modeler 4 from ITP Commerce, which is an add-in to Visio. It can even generate BPEL, but that’s not the focus of the training. We’re still working on the final touches of the simulation parameters and reports, but getting ready for a formal launch around the end of the year.
I’m hoping that with a critical mass of business analysts understanding how to use full BPMN correctly and effectively, tool support for the standard will improve and become even more widely available. And at this stage of BPM market evolution, that’s exactly what we need.
