06.29.07
BPEL Who Need People – Part Deux
As we noted a couple days back, the SOA and BPM crowds both think that services and process management are valuable, but they just can’t agree on how processes should dynamically come together at run time.
At first glance, the arguments are over technology – what we’ll call the WS-folks have put their faith behind BPEL (Business Process Execution Language). It’s an XML-based language that’s an Oasis web service standard that provides the verbs for how services can be dynamically chained together, or “orchestrated” at run time. The WS-folks admire the design simplicity of a declarative orchestration scheme that neatly fits atop the web service stack.
Conversely, the BPM folks believe that their management tools are better equipped to design or dynamically compose those processes. While BPEL might be suited only for machines invoking services off each other, they claim it runs out of gas when it comes to orchestration complex, long-running processes. If you’re going to do serious orchestration, better do it upstream with BPM tools that are far more robust.
At the root of the hubbub is a cultural tug of war between IT and the business that has long predated this particular battle. It goes something like this: IT contends that it is the expert at run time automation, while business analysts claim they have a better handle on the subtleties involved in designing processes. IT complains about the unreasonable requests from business stakeholders who have no idea how their requests will tax the infrastructure. By contrast, the business folks often complain that IT bastardizes their ideas at implementation.
Fast forward to the present, and the WS-folks have proposed a couple new specs to add support of manual tasks, filling a major gap in SOA. The first is an extension of BPEL called BPEL4People that inserts a human task to an orchestration, and the second is a separate spec called WS-HumanTask which provides the semantics for describing the tasks. It’s prompted plenty of discussion, which my colleague Joe McKendrick summarized quite well.
You can imagine the response on the BPM side –- they view these are lowest common denominator approaches that won’t support the way people really work today. “This is where the workflow world was 5 – 7 years ago. In the modern world, people are starting to rely more on run time processes such as ad hoc collaboration,” claimed Rob Risany, vice president of product management for Savvion. Jon Pyke, director of the Workflow Management Coalition (WfMC) is concerned that task implementation conflicts with existing workflow standards, such as XPDL which dates back to the document management era.
But if you take away the polemics, there’s potentially more common ground than may meet the eye.
Yes, the WS- proposals are considerably simpler and won’t represent the richness that you get in the BPM world. But on the other hand, if you apply the 80/20 rule, chances are there are a few simple, commodity tasks that won’t require all the logic of BPM, which might be handled more economically with orchestration at the services, rather BPM level. For instance, a routine request to boost credit limits by 15% for good customers is probably a much simpler decision than one for a customer emerging from bankruptcy.
Admittedly, you might not want to split decision paths for the same process into two different buckets, but that might be doable if you split paths at the line of business or product level. Secondly, by splitting WS-HumanTask into a separate spec from BPEL, it frees the possibility of reusing those commodity tasks in other applications, avoiding the orchestration dilemma altogether.
There’s also another interesting idea coming down the pike that might bridge or bypass the issue – or further entrench the factions. It’s the idea of making process models directly executable.
Modeling provides a way of abstracting the design of a process or a piece of software at a level high enough that business analysts could understand it. It’s been done with UML for architecting software logic and structure, and it’s increasingly being done with BPMN, the business processing counterpart of UML, for business processes. But to get to code, you had to either manually interpret the models, or use a tool that automatically generates code.
But a small Swiss firm, E2E, is now making UML models executable by stealing a trick from Java in adding what’s called ‘byte code.” Lombardi is among the BPM crowd considering a similar idea with BPMN (although BPMN might require some fleshing out with semantics to make the notion doable). And BPEL-J might beef up BPEL with some Java logic that might fill some of its gaps.
Admittedly, these ideas remain for now pie in the sky. But if we can drop the culture wars for a moment, maybe there might be a way to get Venus (the process folks) and Mars (the SOA crowd) to stop sniping at one another.