Change Agent: BPM With or Without SOAChange Agent: BPM With or Without SOA

Business process management vendors love to pepper their marketing pitches with references to service-oriented architecture. To process owners, it makes the software sound cutting-edge, and to IT executives it aligns BPM with their top strategic initiative. But with most BPM today, a real connection to SOA is still somewhere over the horizon. BPM and SOA address different concerns, and to date their implementations have had little to do with each other.

You can do BPM without SOA and still get all the promised benefits, but as processes and process components proliferate in your organization, building BPM on SOA will make the complexity more manageable and more adaptable to change.

Both BPM and SOA talk about agility, reuse, business-IT alignment, service level agreements and BAM. But in reality, they're quite different.

• BPM is top-down and business-driven, and starts with the end-to-end process. SOA is bottom-up and IT-driven. It's about creating reusable components, and it starts by factoring the world into atoms of reuse--business services--that can be consumed by any number of processes or applications.

• BPM strives to solve pressing business problems today. SOA strives to manage IT complexity over the long term, creating an infrastructure for solving multiple business problems in the future.

• In BPM, what is reused is the process model or design. It is transparent--you can see its steps and tweak them in your own variant. In SOA, what is reused is the service implementation. It's inherently opaque, its inner workings invisible.

• In BPM, a business process is inherently hierarchical, composed of nested and chained subprocesses, its performance measured end to end. In SOA, services are inherently independent. How services are orchestrated in various business solutions is not part of the architecture.

The reason BPM suites can claim some relation to SOA is the way they integrate external systems. Middleware components called integration adapters effectively wrap each system so its APIs look like Web services. That enables the BPM suite to orchestrate the APIs graphically. Compared to the costly custom programming required a few years ago, this is agile business integration, so it delivers on the promise of SOA.

But orchestrating adapters this way is not really SOA. For one thing, individual APIs are not business services. They're too low-level or fine-grained to be practical units of reuse. They must be consolidated into coarser-grained business services managed as enterprise information assets in service repositories. Potential users of the services must be able to find them in service registries and connect to them reliably over an enterprise service bus (ESB).

ESBs also provide another critical element of SOA called "loose coupling," in which the actual interface to a system providing a service, such as an ERP system, is hidden behind an abstract proxy service in the ESB. For instance, you could hide three different ERP systems, with three different native interfaces, behind a single proxy service. A getCustomerInfo request to the ESB would be routed and translated as required to the right ERP endpoint, and the requester would never have to know which ERP system was involved.

The artifacts of an SOA suite--repositories, registries, ESBs and associated tools and management utilities--are almost never part of BPM suites. Process designers don't have a way to easily search registries to match available business services to process activities. BPM suites are not designed to leverage the loose coupling benefit of ESBs.

The converse is also true. Most business services created in SOA suites are fully automated, with no human tasks. Yet the examples promised to the business, such as a loan approval or claims payment service, must include human tasks, and you could build them using BPM. But show me a BPMS/SOA combination where a business process populates an enterprise service repository or registry, or creates a proxy service on an ESB. The connections just aren't there yet.

If you think about BPM as a solution to one business problem, doing it without SOA works just fine. But as it becomes more of an enterprise platform, the links between BPM and SOA must become stronger, and reinforced with methodologies that let them work together effectively.

Bruce Silver ([email protected]) is an independent industry analyst and author of the blog BPMS Watch. Engage in the discussion at www.brsilver.com/wordpress.