News

BPM Learns To Play With SOA

• By Lee Thé
• July 30, 2007

"It's hard to find BPM folks who are not talking about SOA, and vice versa," Baer said. "And of course, if you use BPM tools, I doubt that  you'd continue using one that didn't let you expose your processes as services."

Baer also finds both camps often talking past each other. Business folks are unimpressed with IT's understanding of business processes, while the IT side argues that their business counterparts don't get issues such  as capacity and load management -- "feeds and speeds."

This dual focus has resulted in BPM and SOA conferences being held that appear to tackle the same issues, yet speak to different audiences. Conventional  wisdom explains this split in terms of actions: BPM models, while SOA  executes. Baer agreed -- to a point.  True, he said, both aim to integrate and reuse processes. Both expect that  reuse will accelerate time-to-benefit, save money, spread best practices and improve consistency. Both codify processes to improve business agility. And both use the "b" word in the terms of using "business process modeling" and "Business Process Execution Language" (BPEL).

He added that the BPM and SOA crowds seem to agree that going forward, more and more business processes will be deployed as services in one form or another. And SOA's emphasis on loose coupling dovetails perfectly with the BPM stress on process agility. Consequently, most BPM tools support  exposing processes as Web services, essentially making SOA an execution layer  for business processes in the service tier.

Clash in Culture and Methodology
Baer sees a methodology cleavage between BPM and SOA. The business folks view BPM as a way to help rationalize the business. IT sees SOA as the latest, greatest integration technology architecture. IT uses SOA to  build services that execute business processes. However, being IT, they also need to ensure that all of those services are compatible. This requires consistent semantics, consistent support of Web service standards and support for orchestration, where you conditionally chain a number of Web services  together.

IT regards SOA as the latest integration approach for apps and databases, stretching all the way back to the computer-aided software engineering (CASE) tools of yore. And IT likes SOA because it sees a critical mass of standards coalescing to make SOA feasible, as well as more generic and less breakable than its predecessors, such as enterprise application integration (EAI) systems. And SOA stands on the shoulders of traditional object-oriented (OO) programming.

"Peel the skin off a service, and what you have is a declarative component that has been designed with OO principles, and has a messaging piece that connects service requests to service providers," Baer explained.

In that light, SOA represents a supple, lightweight realization of good old CORBA (Common Object Request Broker Architecture). All of this means that the IT implementations are more likely to actually work.

In theory, it also means that BPM implementations are more likely to serve the enterprise's most critical needs, such as improving business agility and reducing operational costs. However, the cool proof-of-concept prototypes may not scale properly, nor provide needed reusability and interoperability.

Moreover, the splits abide. The business process folks work with diagrams in business language, while the IT folks work with logic that executes on a computer. BPM building blocks include process modeling and simulation, process execution, process monitoring and workflow. SOA building blocks include SOAP, WSDL, UDDI and other Web service standards. BPM talks  about process management and integration. SOA talks about process orchestration using BPEL, BPEL4People and WS-HumanTask. The conflict comes when the IT folks expect to take discrete process steps and orchestrate them all in BPEL, while the process folks want to do this further up the stack at the core business and process logic level.

Marry BPM to SOA With BPMN
The more business-aware IT people realize that everyone needs a way to get from business logic to something computers can execute competently and effectively. Increasingly, many on the IT side are looking to the OMG's Business Process Modeling Notation (BPMN) to back up BPEL with process logic --  not fill it in, because Baer doesn't believe BPEL can do that. Still, the  BPMN-BPEL connection may provide the missing link to translating process logic into a machine executable language, despite the fact that both languages use a  very different syntax.

BPMN provides a visual representation of flow, connecting objects, swimlanes, artifacts and the like. BPEL provides a programmatic representation for receiving, replying, assigning, throwing, waiting, exiting and the like. BPMN lacks a full business context, but does address organizational structure, functional breakdowns, strategy and rules. BPEL lacks a full process context, but it is suited for triggering automated steps.

According to Baer, the latest battleground centers on trying to add human workflow to BPEL via two proposed OASIS specs: BPEL4People and WS-HumanTask. IBM, BEA, Oracle, SAP, Adobe and Active Endpoints are all involved. The rationale stems from the fact that most business processes are not 100 percent automated. So if you're triggering an orchestration, you need a way to get a person into the decision loop -- sort of the software equivalent of a cyborg.

This proposal is coming from the IT side more than from the business side, which seems to see the new proposal as reinforcing the old divisions.

"What's not surprising is that this has not exactly become a 'Kumbaya' moment for the BPM world," Baer said.

At this juncture, Baer predicts coexistence, with BPM being used for mainstream orchestrations and BPEL for lighter weight orchestrations. WS-HumanTask won't replace workflow, but it will provide a way for reusing extremely rudimentary tasks for SOA exceptions. There will be some BPEL, but he'd be surprised if you saw much BPEL4People. BPEL has become a "checklist item" when customers buy SOA stacks. They expect their suppliers to support BPEL even if they don't have current plans to use it. But BPM will remain the workhorse for the more sophisticated process flex points, simply because the tools are designed to handle it. It handles business context -- organizational roles that tend to be intangibles for BPEL.

Some people are talking about making process models executable, and this is already happening with Unified Modeling Language (UML). Such notions may raise infrastructure questions in the future.

BPEL "will get its day in the sun for very straightforward process execution variations," Baer said, "such as request for raising credit limits of customers already in good standing, or triggering traffic or weather reports when rush deliveries are requested."

Similarly, Baer doesn't think WS-HumanTask will replace workflow. But he regards the decision to separate it from BPEL as astute. It means you could reuse some extremely simple human tasks in any scenario where you're deploying Web services, not just when you're using BPEL.

For example, in the case of credit limits, consider a customer with a decent -- but not great -- credit rating. WS-HumanTask could send the job to a load specialist for a quick yay or nay. And there are a lot of situations like that where human input could be built into an otherwise automated process without overreaching.

Baer's bottom line is that BPM's Venus and SOA's Mars can indeed get together, as long as, like porcupines, they do it very carefully.