Despite the push for open standards in business process management (BPM), customers still risk being lured into vendor-specific frameworks.

	express delivery
	• print  • comment
	Proprietary implementations will undermine the openness of BPEL-based business process orchestration in an SOA: BPEL is seen as key to managing business processes in an SOA It lacks many BPM capabilities, especially human workflow Existing BPM products plug the gaps with proprietary technology Many vendors offer proprietary implementation frameworks Pre-built service definitions favor vendors' own products
	Glossary terms: BPEL, business process, SOA, orchestration, interoperability, lookup tool Sponsored links: your text link here

The most talked-about standard is WS-BPEL (also known as BPEL4WS, and often shortened to BPEL), which many vendors see as a key component of a mature service-oriented architecture (SOA). With the support of big players IBM, Microsoft and BEA, widespread adoption of BPEL seems assured. Due for an upgrade from version 1.1 to 2.0 towards the end of this year, it orchestrates web services into processes that map to business needs — classic examples include an insurance claims process or an order management process. By drawing on a common XML syntax, BPEL-based processes can automate both simple and complex interactions between web services, as well as long-running transactions with compensation and parallel execution.

But while proponents say that the upgrade to version 2.0 represents a significant leap forward for standards-based orchestration of services in an SOA, its detractors insist BPEL is neither necessary, nor sufficient for BPM. "BPEL just doesn't cut it for true BPM," says Wayne Snell, director of marketing at Plano, Texas-based Fuego, one of the earliest and leading BPM vendors with over 200 customers. "It's great for orchestrating services together and for system-to-system processes, but where there are complex services or where people are involved with the system, for that to take off, you have to have something more."

Even the BPEL technical committee at OASIS admits that where manual tasks are involved or where work is "non-standardized," proprietary extensions will have to be added to the standard. The need to act as a common foundation for all conceivable business processes makes it inevitable the standard itself will be highly generic. IBM's Diane Jordan, co-chair of the BPEL technical committee at OASIS, admits as much when she says: "One of the challenges of the TC has been to produce a high quality standard that meets the use cases of the various interested parties. This is worth taking the time to get right so that WS-BPEL provides a solid foundation and is widely adopted. We're optimistic that we'll see an approved spec in the next few months."

Longer-established BPM players including Fuego, Savvion and Pegasystems started out long before BPEL took shape and have already written their own methods of performing BPEL-like functions, as well as filling in the elements of human workflow that BPEL currently ignores. They envision running these proprietary functions alongside the more recent BPEL developments — at least until the standard is more widely adopted.

This proprietary approach to implementing BPM is complemented by proprietary service-oriented foundations. Fuego has integration capability built into its BPM platform and builds its own SOA to support business processes, cataloging reusable components — or composite services — during and after implementation. Key to this, says Snell, is the concept of catalogs and projects, with IT staff building reusable services as part of a project which then become available to business staff through the catalog (the equivalent of a services registry/repository in a standards-based SOA). Cambridge, MA-based Pegasystems has a similar concept, built around rules (the equivalent of policies and contracts in SOA-speak). "We enable multi-dimensional reuse of the building blocks of processes — reusing sets of rules in the rule base," says Pegasystems technical director John Everard. "We then call them into a process structure, with our Process Commander."

Everard claims that the current version of BPEL is limited in its aims, but adds the future 2.0 could take orchestration to the next level: "People have been talking about standards a lot and now we are just starting to see them taken on board. There is slight confusion though because originally BPEL was just a language for describing processes you could call as web services — now it's expanded to become a language for the whole process so you can port processes from one application environment to another."

He explains that the ultimate goal is that you can search a directory for a service in one tool, define it as part of a process in another tool and then send it on to an engine for execution. Everard adds: "Ultimately, IBM, BEA and Oracle will become BPEL engines that can consume processes from elsewhere and we will be a provider."

This service-oriented vision of BPM as a sequence of discovery, assembly and provisioning seems to imply a final destination where customers are free to shop between BPEL platforms. Long before the vision becomes a reality, however, vendors aim to tempt customers with pre-packaged business process frameworks and implementations that will keep them tied in to their own offerings.

A key part of IBM's SOA announcements last month, for example, was a set of industry accelerators — best practice templates, reference architectures and process models for key vertical industries. In addition, IBM Global Services says it will package common reusable assets such as inventory management and claims processing in a common services delivery platform. "You could write all this stuff on top of our application server, but the richness of the platform provides you with an integrated environment," says VP of worldwide application and integration middleware R&D Tom Rosamilia, emphasizing the convenience of the prepackaged solution. "It's not just repackaging a lot of existing content — there are brand new products and enhancements to existing products."

Analysts positively encourage clients to look for vendors which can demonstrate templates in their particular vertical, but packaging up blocks of processes in this way can undermine many of the benefits of working within open standards. Furthermore, Fuego's Snell claims that customers don't actually need templates. "The analysts say all customers need a [BPM vendor] with subject experience and process templates to jumpstart them. But we see over and again people asking for templates, but when it actually comes to buying Fuego, they don't use them."He says this is because customers need to develop processes for their own particular business, based on their experience of using the system. "We have a customer here in Dallas, who is an insurance claims processing company — it handles the claims for a lot of the big insurers. This company has saved $4.50 per claim by using our product, but it has gradually evolved to that point: it has 99% automation right now, but when it first implemented Fuego it had only 78%. It had a rule that if a business process had to be fixed 15 times over a three-month period, it required a new business rule."

IBM itself has a strong track record in insurance, and takes a diametrically opposite view of the value of template frameworks. A team working for the past 20 years at an installation in Dublin, Ireland, has developed what the company calls the Insurance Application Architecture, consisting of business process models, terms, data architectures and machine states. IBM recently handed over 120 of these models to the insurance industry standards body ACORD (Association for Co-operative Operations Research and Development) to develop into common industry standards.

"Where we believe the industry is developing is towards common service definitions across different companies," says Cindy Maike, global market segment manager for insurance at the IBM Software Group. "Web services will be built out as you look at interoperability across carriers, re-insurers, third party repairers, banks and so forth." ACORD already has a set of message format standards, but is increasingly moving to business processes that sit above these and link them together.

The initiative sounds noble — but it may not be as selfless as it first seems. IBM has already built accelerators for the models handed over to ACORD into its middleware — the WSDL service descriptions and the BPEL orchestrations that implement the actual processes. If the processes do become a common industry standard, then IBM will have created a hugely improved opportunity to sell more product.

More on this topic