06.26.07
BPEL Who Need People
A truism about SOA is that it’s all about automating the interaction of processes that are already automated. In other words, an SAP or Oracle supply chain application might invoke a weather forecasting service from an external program and automatically adjust promised delivery dates without the need to get a human involved in a process.
But of course, if business only relied on automated processes, then the world would look like something out of a Jetsons cartoon. In actuality, sometimes you can’t fully automate processes such as that delivery date commitment decision. Suppose you needed to make a delivery commitment to the Gulf Coast just before Katrina was to strike? Short of possessing true AI and a crystal clear crystal ball, you’re going to have to call a person into the process where the scenario is so exceptional that it requires human intuition.
This week, IBM, joined by SAP, Oracle, BEA, Adobe, and Active Endpoints formally proposed a pair of specs for submission to Oasis, the web standards body, which would make human workflow a first class citizen in an SOA environment (for now, we’ll call this group the WS-folks). There was little surprise to the announcement, except for the fact that Oracle dropped its former opposition to the scheme.
The new proposal boils down to two specs: an extension of BPEL that adds human workflow as one of its orchestration steps, and a new proposed spec, WS-Human Task, where the actual workflow would be described. Backers claim that, by separating out human tasks, that they can stand alone and be invoked without having to go through a BPEL orchestration. That would enable you to decouple the task from the actual application or user interface, making it that much more reusable.
This all sounds fine and dandy except for one thing -– the classic BPM folks are still not among the signatories. Both sides have been warring back and forth, with many of the established BPM players claiming that BPEL is simply a rudimentary execution language that does not reflect the subtleties of a process workflow. For instance, it doesn’t represent core concepts like “swim lanes” that are used for describing parallel activities. They claim that BPEL in fact complements a couple other standards, including BPMN, a graphical notation for process models, and XPDL, an older specification first developed by the document management and workflow communities.
As for the WS-folks, the claim is that XPDL is not service-oriented, in that it does not separate loose couplings where processes are abstracted from the way they are implemented. And to rub it in, they actively denigrate XPDL as “old fashioned” in its traditional association with paper pushing.
Or as one colleague put it, the BPM folks are from Venus and the WS-folks from Mars.
Our first inkling is that regardless of the merits of the classic BPM crowd, it’s kind of difficult to move forward when you’re facing a solid roadblock guarded by IBM, SAP, Oracle, and BEA. But we’re also disappointed that the WS-folks have not conducted any outreach to the BPM folks. Although they exert strong control in the increasingly strategic middle tier, the process folks come from a different side of the organization than IT –- and if there is no common ground soon, the only result will be stalemate.