The awkward dance between BPM and SOA

Does business process management (BPM) need SOA to go forward? Does SOA need BPM to be relevant? Are they one in the same? Or are they completely different animals?

Depending upon whom you read, BPM is either worlds apart from SOA, or the two are fused right down to the genetic level.

Nick Malik, for one, refers to BPM and SOA activities as analogous to "twin brothers." As enterprises move toward event processing, they will be drawing on both SOA and BPM to establish a common data model and manage events that form the boundaries between business processes. SOA and BPM need each other.

I also heard Forrester's Ken Vollmer note at the ebizQ online conference a few months back that attempting BPM without SOA is like "having one hand tied behind your back." SOA "provides a more standards-based approach of doing BPM," he said. "First, the notations that come out of the initial modeling process can be exported into standards such as business process execution language (BPEL), "which then, in the form of XML, can be executed inside the execution engine." Then, foundational standards such as SOAP, WSDL and UDDI "support the interaction between the business applications and the modeling tools. If these standards did not exist, the model-driven development in the BPM tools would not be possible."

However, not everyone agrees that SOA and BPM are such a perfect pair. Steve Jones, for one, recently questioned the notion that "a service is a specific business process step that can be composed and reused in different business processes," calling it "completely and utterly wrong."

Steve is no lightweight in this market, as he is the head of SOA and SaaS for Capgemini’s global outsourcing business, member of the OASIS SOA Reference Model group, and author of a number of technology books, including Enterprise SOA Adoption Strategies.

The problem, Steve says, starts on the BPM side, with efforts that seek to address services as "steps." As a result, he says, "every service looks like a step."

What's wrong with that? Steve says that in the process, legacy function calls merely get swapped out with new protocols, but that does not a service-oriented architecture make. If you are using a BPM approach and saying "step = service," then "you are doing VISUAL Cobol and replacing function calls with service. The fact that you are using WS-* or XML does not make these elements 'services.'"

In essence, he says, "BPM-driven SOA tends to make bad SOA as it is driven from a procedural and process view, has poor separation of concerns and is mostly all about driving things from the technology perspective. SOA makes great BPM, BPM makes crappy SOA."

Strong words, indeed. And, ironically, Steve is arguing that BPM-driven SOA is too technical. That's one of the greatest arguments around SOA, is that it needs to be business-driven, and linking SOA to BPM is seen as a way to introduce business drivers to the effort.