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.
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.
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!):
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.
There are no products in your shopping cart.
| 0 Items |
Membership at BPMInstitute.org includes access to our other communities
