I feel pretty strongly about the benefits of standards in all areas of technology, and BPM is no exception. For years, we’ve been using different notations in different tools to create BPM systems that don’t communicate with each other because they speak a different language. There’s been a lot of headway in standardizing the communications part — the messaging protocols, for example — but there’s still work to be done in the design end. How can we hope to make BPM systems truly interoperable when they don’t use the same notation to model the flow within the system?
Every BPM system has its process designer tool, but when it comes right down to it, most people model their process in Microsoft Visio before implementing it in the BPM system. First of all, a lot of people already have Visio on their desktop and know how to use it, so there are less licensing and training issues. Secondly, a process model will usually include all sorts of non-automated steps that will never be represented in the BPM system (especially the “as-is” model), but need to be modelled for proper business analysis. I’m not interested in tools, however, but in the actual BPM notation, which can be drawn in Visio or any number of other process modelling tools.
There are standards emerging for BPM notation, with two strong contenders: UML activity diagrams, and BPMN business process diagrams. If you have a technical background and haven’t had your head in a paper sack for the past 10 years, you know about UML; however, you probably know it as a modelling tool for software design, with activity diagrams being used for computational processes, which is why the OMG originally developed it. UML activity diagrams have recently been repurposed for business process modelling: a type of object-oriented flowchart, if you please.
As much as I like UML for software design, I like the emerging BPMN standard (from BPMI, an industry standards body) better: it’s been designed as a business process modelling notation, not retrofit from some other standard; it’s more understandable to business analysts and other non-technical participants; and it has a direct mapping to WSBPEL for process orchestration. It was only introduced last year and may take a while to catch on, but it’s worth knowing about.