That code sometimes takes the form of UML (Unified Modeling Language), which has been used since the mid-’90s to describe the behavior of object-oriented software systems. But today, the buzz is over BPEL (Business Process Execution Language), a standard for orchestrating the way Web services interact. Most BPM modelers generate BPEL code, and all major software vendors have endorsed the standard, even though the BPEL spec is immature and BPM systems must use other means to fully orchestrate processes (see A developer's perspective on BPEL).
Business processes to go?
“The power of BPEL is not that it’s a robust orchestration language but that it’s portable,” Grand Central’s Linthicum says. In other words, just as the J2EE specification provides marginal portability for Java components, BPEL will eventually open the possibility of transporting business processes from one BPM platform to another. Customers want that kind of investment protection, Linthicum says, even though it’s a long way off.
“You’re selling a concept without reality. It’s the same way we sold Java and C++ in the early days,” Linthicum says. But with the enormous momentum behind the standard, Linthicum gives it an 80 percent chance of success.
“We like BPEL from the point of view that it does provide us with some very nice constructs for orchestrating Web services,” Tibco’s Quinn says. “And at some point, when more vendors start to support it, portability will become a little bit easier at a high level. But when I look at the problem of business process automation and integration in general, BPEL addresses maybe 3 percent of the total effort.”
The rest, Quinn says, lies in making application functionality available as Web services — because BPEL can orchestrate processes composed of Web services alone — and in filling in orchestration functionality that the BPEL 1.0 (and draft 1.1) specification lacks.
The generally accepted estimate is that it will take approximately 18 months before BPEL matures into a robust orchestration language. Meanwhile, enterprises will have time to build out their SOAs, making the whole BPEL proposition more viable.
In the interim, BPM vendors tend to use other means to describe the interaction of processes at a technical level. Intalio, for example, employs BPML (Business Process Modeling Language), a much more robust specification that predates BPEL, but one not designed to orchestrate Web services.
The other up-and-coming BPM standard — although it lacks the traction of BPEL — is BPMN (Business Process Modeling Notation), which seeks to standardize the way BPM modelers graphically depict processes.
“We think BPMN is interesting,” Lombardi’s Favaron says. “The idea is that it would be portable and consumable and integrated into everybody’s modeling environment. There’s really no good way to take a high-level business modeler and translate that into the actual working process today.”
Ultimately, Tibco’s Quinn and others doubt whether process portability will be truly practical, given that vendors always differentiate by adding proprietary functionality.
But portability is a secondary benefit. The promise of BPM for IT is in providing the missing organizing principle for SOAs, enabling ultrafast application development and change management with minimal new coding. For the business side, the payoff is a new ability to conceptualize, deploy, measure, and reconfigure business processes quickly, without getting lost in the no-man’s-land between business and IT.