You can’t attend a BPM conference or webcast nowadays without hearing how SOA provides the critical technology underpinnings of BPM software. And there is even a grain of truth in that statement. For example, most BPM Suites provide integration adapters that can introspect backend systems and turn them into process components that are, in an important sense, service-oriented.
You can’t attend a BPM conference or webcast nowadays without hearing how SOA provides the critical technology underpinnings of BPM software. And there is even a grain of truth in that statement. For example, most BPM Suites provide integration adapters that can introspect backend systems and turn them into process components that are, in an important sense, service-oriented. Regardless of the internal platform, programming API, or data model of the backend system, the integration adapter can expose functions of that system via XML parameters, perhaps even an actual WSDL, and allow the process engine to orchestrate them without code. That’s huge, really the key to making application integration more and enabling point-and-click composition of end-to-end process implementations.
But in the SOA world, that’s not really SOA.
If you go to an SOA conference or webcast, you’ll find they talk little about orchestration and almost never about integration adapters. Instead, you’ll hear a lot about architecting collections of business services, the fundamental units of reuse across the enterprise. You’ll also hear about tools to build those services, repositories and governance policies to manage those services as long-lived enterprise assets, and registries to advertise them for discovery by solution developers. Of course, you’ll hear about graphical tools to orchestrate services in composite applications, but you’ll hear a lot more about an enterprise service bus – the scalable communications infrastructure interconnecting those services – and the ESB’s elaborate instrumentation to monitor service levels in real time.
Certainly, there will be some hand-waving about SOA enhancing business-IT alignment and BPM, but nothing concrete in the toolset to support it. Once they mention BPM, there is again a disconnect from reality. Orchestration is not BPM.
BPM is business-driven. It’s about optimizing and improving business performance at the end-to-end process level, innovating the business, making it more efficient, faster, more agile, more compliant with policies and best practices, and more measurable. It’s top-down because it begins with the end-to-end process.
SOA is IT-driven. It’s about transforming IT infrastructure, leveraging existing investment and breaking it into reusable parts, providing a high-performance reliable communications fabric for interconnecting those parts, and managing those parts for optimal discovery and reuse. The goal is making solution implementation faster and less costly, but it’s bottom-up because it begins with the parts, not the end-to-end solutions.
BPM and SOA are both important, and they should be used together. But today at least, they’re not.
So why do I say that most BPMSs today are not really layered on SOA? No architected business services, for one thing. Process components generated by integration adapters, for instance, are easy to create, but they are not architected as optimal units of reuse. Also, there is no enterprise service repository, no enterprise service registry. Well, there is probably a catalog of service-like components managed at the process or project level, but nothing to manage them as long-lived assets at the enterprise level. And there is no enterprise service bus.
The absence of an ESB is the most readily identifiable sign of a BPMS that is not really layered on SOA. In fact, in some ways the functions of an ESB are at cross-purposes with those of the BPMS process engine. For example, ESBs provide data transformation and content-based routing of messages from one service to another. Wait a minute, isn’t the process engine supposed to do that? Instead of managing all the process logic in one place – the process model, executed by the process engine – it’s now split into two, part in the process engine and part in the ESB.
ESB providers use a phrase that you never hear from BPMS vendors: loose coupling. Loose coupling is a central tenet of SOA and a core feature of the ESB. It means that a business service is a logical description of a function, not hard-wired to any particular implementation of that function. The service may be provided by replicated instances of a system throughout the enterprise, or even by a variety of diverse business systems, or by third party providers. Optimal reuse of the business service means the implementation of that service can be selected by logic independent of the process model, and can change over time without composite applications or business processes that use the service having to change, or even having to know. All the necessary selection, mapping and routing is done by the ESB.
That’s not how most BPMSs today work. In the usual arrangement, the integration middleware of a BPMS introspects a particular service endpoint (i.e. implementation of the function), not a logical description of the function mapped to an endpoint by ESB logic at runtime. A BPMS process design tool that is expecting to use the mediation logic and adapters of an ESB would look a bit different than one that is expecting to use its own adapters and data mapping, which explains why it’s not a trivial matter to simply layer BPMS from vendor A on top of an ESB (SOA Suite) from vendor B. Today, if you want a true BPMS layered on true SOA, it’s easiest to get it pre-integrated from a single vendor. There are a few vendors providing it now, including IBM, Cordys, and webMethods, with BEA and Oracle, among others, waiting in the wings.
We must not lose sight of the fact that a BPMS without an ESB, enterprise service repository, governance framework, or registry still provides great business value and is all you need in many – probably most – situations. Creating architected business services and rolling out SOA infrastructure is a multi-year process that still is in its early stages in most companies, while BPMS lets those organizations build real solutions today.
So where is it most important to look for BPM layered on top of real SOA? Today the sweet spot is with high-volume, mission-critical, transactional processes with a heavy emphasis on system-to-system integration, as opposed to human-centric or collaborative processes. Another sweet spot is where service reuse and the benefits of loose coupling outweigh BPM’s more immediate benefits. For many organizations, that is still a few years off.
While BPMS layered on SOA is today the exception or special case, that won’t always be so. As BPM merges into the mainstream IT infrastructure, this layering will become the norm, and BPMSs will likely be able to work with any of the popular ESBs of the day. But we’re not there yet.
