The following is my latest column for BPM Institute:
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, integration adapters can expose functions of those systems 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 agile 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 that will be 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.
Nice article – I reckon you might want to include TIBCO in your list of those vendors providing BPM over SOA now…
Indeed nice article, but I’m stunned to see that Microsoft again is not included in the discussion. They have an end-to-end BPM/SOA/ESB solution with the complete loose coupling and service orientation as discussed. It’s time to start comparing them to the other vendors too. Keep up the good work! Chris
Not sure I 100% agree with you Bruce. Looks like since you started asking about the difference between BPMS and ESBs, someone gave you a bit of religeon (the ESB side of the equation). I wonder who that might have been …
I don’t really understand how you can say that a modern BPMS does not support “loose coupling” … well I suppose you didnt exactly say that, you just implied it. I hear plenty of BPMS vendors talking about loose coupling … it is just a question of who you ask. Also, I would regard that concept as a design goal of good process design, rather than an inherent capability of the underlying infrastructure.
I’d like to hear more of that MS end-to-end BPM/SOA/ESB – it’s news to me …
Chris, Ric…
Either of you may be right about Microsoft. I wouldn’t really know. It’s hard to cover a company that won’t let you talk to anyone but the PR agency. I’ve about given up on breaking through the MS information shield. In Colbert’s words, Microsoft, you’re “on notice.”
–Bruce
Derek,
I don’t think I’ve been brainwashed by IBM, Cordys, and webMethods, if that’s what you’re saying. It’s more like I’ve been struggling for a while trying to understand why attendees at the Brainstorm BPM conference and the SOA conference in the next room have so little to say to each other, i.e what really is the relationship between BPM and ESB (and all the other SOA goodies). I just put out how I’ve made sense of it, and so far no one’s said I’m wrong. Sure, BPMS pureplays may say “loose coupling” as part of their SOA shtick, but please expand on what that means. As I explained it in the post, it means the logical-to-physical mapping happens in the ESB not in the process model. Conceptually that computes for me, although I noted the problem with it (logic is split into 2 places). If that’s not correct, please set me straight.
–Bruce
BPM and SOA 2…
The separation between Inside/Outside (or Private/Public) is of course a crucial element of the component/service story. The belly of the whale is a metaphor for encapsulation. In Frye’s version, BPM is on the inside and SOA is on the outside. From a …
[…] I think I know quite a bit about BPM, and while I can’t say the same about SOA yet, I’m trying hard to learn. Still, I already know enough to say that when a BPMS vendor talks about how his product is based on SOA, he’s not talking about the same SOA that the real SOA guys are selling. Including things like loose coupling, supposedly a foundational SOA concept. Nobody talks about it, it blows my mind! And 99.9% of what is written about the intersection of BPM and SOA is either irrelevant or plain incorrect. […]