Standards and the Process Lifecycle

In the BPM world, like the world in general, standards are like motherhood and apple pie. Vendors and buyers alike are vociferous in their support. After all, standards reduce the costs of vendor lock-in, simplify training and support, reduce risk of vendor failure, facilitate component integration and reuse, support interoperability of systems and processes, expand the choice of compatible technology, and promote agility in a changing world. Who could be against all that?

But if you ask around the BPM community about the current state of standards, you hear words like “confusing,” “chaos,” “a mess,” “a disaster.” Ironically, the mess is a direct result of recent progress in the standards committees. The problem with BPM standards is we now have so many of them, often overlapping but coming from different standards bodies and seemingly at cross-purposes.

At the heart of the BPM standards question is the process description, or model. In most people’s minds, standardization in BPM implies universal understanding of modeling language and diagram elements, portability of models between design tools, and interoperability of models across process engines. This kind of standardization, on which the promised business benefits depend, assumes three things: widespread acceptance and adoption of a single standard within a functional domain, completeness of functionality encompassed by that standard; and mutual compatibility of standards across functional domains. This is precisely what we don’t have yet in BPM.

In their 2002 book Business Process Management – The Third Wave, Smith and Fingar envisioned a new type of software, the BPM System (BPMS), in which a business analyst could graphically compose a process model, optimize it through simulation and analysis, and – perhaps after a slight technical tweak by IT – execute it on a built-in process engine. All this would be done in a single design tool, part of the BPMS, using a functionally complete, standardized modeling language.

While this vision remains compelling (to me, at least), the reality of BPMS in the process lifecycle today is more complex, and core to the standards issue.

• Business analysts use dedicated tools to graphically model processes in the form of diagrams that can be annotated to allow simulation and analysis, but which lack the technical detail required for execution. Let’s call those analytical models.
• System architects then interpret those models as business requirements and proceed to describe data elements and software components needed for implementation, using enterprise architecture modeling tools.
• IT developers next create these components using programmer tools (IDEs) and integration middleware. Increasingly today such components are being architected as reusable “services.”
• In the BPMS design environment, process designers import analytical models and convert them into executable models by linking them with the developer-built components. These executable models can be deployed from the design environment to the BPMS engine to automate and manage the process.

In the real world of BPMS, a “process designer” is usually a bit more technical than a business analyst, but a lot less than a Java programmer. In many ways, the “spirit” of The Third Wave is being achieved, but instead of business analysts implementing executable processes directly, the real lifecycle involves handoffs between distinct constituencies with different skills and concerns, working with different modeling tools.

This is one source of the BPM standards issue, since each standard is typically focused on one of these constituencies and one particular phase of the process lifecycle.

• For example, the Business Process Modeling Notation (BPMN) from BPMI.org standardizes the meaning of shapes and lines in the process diagrams used in analytical models. While still meant for business analysts, BPMN goes beyond simple flowcharting to represent advanced features of modern service-oriented BPMSs such as message links, events, and transaction compensation. Currently BPMN is just a diagramming standard; it has no underlying language or schema. Models must be mapped to a common execution language (BPEL) to be portable across tools.
• Component models used by enterprise architects typically are based not on BPMN but on a different modeling language, UML from the Object Management Group. UML includes a variety of diagrams, some of which – activity charts and statecharts – also describe process flows.
• The language used by a BPMS for executable modeling depends on its underlying product architecture. There are two basic types: Workflow architecture, based on the well-established reference model of the Workflow Management Coalition (WfMC), features models based on XPDL from WfMC. Process models based on service orchestration architecture have committed to the Business Process Execution Language (BPEL) from OASIS. While you often hear that BPEL is an “execution language, not a design language,” the fact remains that in a BPEL-based BPMS, the design environment invariably features diagram elements that correspond one-to-one with elementary BPEL activities. In other words, in the real world BPEL is being used as a design language – for process designers technical enough to use it.

The second piece of the BPM standards issue is that both XPDL and BPEL omit major elements of real business processes from their respective languages. In XPDL, application integration logic is embedded in process activities, i.e. external to the process model. In BPEL, participant roles and other details of human interaction are embedded in services, again external to the process model. Thus to handle real-world business processes, the BPMS must either support hybrid models, part XPDL, part BPEL, or – the usual solution – simply add the missing functionality as proprietary “value-add” outside of the language standard. While the most functionally complete BPMSs tend to use the workflow/XPDL architecture, support for BPEL from IBM, Microsoft, BEA, Oracle, and SAP – and its inclusion in the web services standards “stack” – has led most analysts to declare BPEL the presumed “winner” of the BPM standards battle.

With this as background, let’s revisit the current state of BPM standards (warning – alphabet soup ahead!):

• BPMN diagrams, having no standard language or schema, are not portable between analytical modeling tools. They can only be mapped to BPEL. But while BPMN can describe human activities, the details of human interaction cannot be mapped to BPEL. They have to be added in the BPMS’s BPEL tool, which, as discussed, is not well-matched to non-technical process designers.
• BPMN has no mapping to XPDL. Even if BPMI.org wanted to provide this, XPDL today does not support everything in BPMN. That means XPDL-based BPMS vendors have to add BPMN tools to their own design environment, usually with less functionality than the analytical modeling specialists.
• OMG is working on its own Business Process Description Metamodel (BPDM). Rather than compete with OMG, BPMI.org is hoping to work with them to develop an underlying schema for BPMN based on BPDM. But that work appears over the horizon, and OMG really serves a different constituency in the lifecycle. Others say BPMI.org should just standardize the BPMN schema and be done with it.
• Neither BPEL nor XPDL are functionally complete. Some information described in BPMN cannot be mapped to the execution language. Real-world BPMSs have to add this functionality in vendor-proprietary portions of the executable model, making those parts no longer portable.

Confusing and messy? That’s fair. Chaos is a bit extreme. It’s certainly not a disaster. It’s fixable.

That at least was the mindset of BPMI.org when they convened a summit of leading BPM users and vendors, together with honchos from OASIS, OMG, and WfMC, in Miami this month. There was a published agenda, but the details of the event were left intentionally ad hoc. The outcome took me by surprise.

I went in thinking that XPDL was a non-starter, a relic of the client/server ‘90s. I believed that the key task was an initiative to extend BPEL, the obvious “winner,” to handle human interaction, the biggest missing piece. There had been leaks to the press about something called BPXL – human workflow extensions to BPEL that the technical committee in OASIS didn’t have the bandwidth (or perhaps the motivation) to attack.

But it turned out that the majority of users and vendors in attendance had no interest in BPEL at all. In fact, most would characterize it as a sort of 4GL for composite applications using web services, having little to do with business processes as understood by the BPM community. And that’s probably not unfair. The “BP” in BPEL, depending on one’s point of view, could be viewed either as a historical accident or a classic bait-and-switch. Certainly the community of programmers interested in composite applications using BPEL is distinct from – and larger than – the community of business process management.

Among attendees at the summit, there was far more interest was in “fixing” BPMN – giving it a metamodel and schema, mapping it to XPDL – and extending XPDL to handle everything BPMN could throw at it, including message links and events. Real work on XPDL 2.0 is well underway, as is the mapping to it from BPMN.

There was another group (myself included), far smaller, still interested in adding human workflow to BPEL. Most likely this would take the shape of a standardized TaskManager (Worklist) service rather than a new activity type in the BPEL language.

If either of these efforts leads to something that is implemented in successful commercial products, we might look forward to a new iteration of BPMS in the process lifecycle – something closer to the Third Wave vision, but with a twist. Instead of creating executable models within the BPMS environment, you’ll be able to build them anywhere, from enterprise architecture tools to specialty modeling tools to inexpensive Visio plug-ins, using BPMN as a business-friendly front end. You just draw the BPMN diagram, simulate and optimize it, and click to compile it to a complete executable process – deployable to any BPMS. In normal circumstances, the execution language will never be seen by the process designer. In some ways that’s even better than the Third Wave ideal, since modeling tools could be selected independently from the BPMS, something enterprise architects probably favor.

Behind the confusion, there is definitely hope for meaningful BPM standards. We’re really just getting started.