There are many IT systems sufficiently compact and stable to optimally support BPM without SOA?at first. If companies choose a BPM suite with sufficiently rich connectivity to underlying applications and databases, they will at first get the benefits of BPM without a SOA. But this initial success contains the seeds of its own downfall: As more departments come online, more managers have a hand in controlling the IT environment. And as the system?s growth necessitates more changes, the BPM solution will soon be suffering the coordination, integration, and management problems SOA was invented to solve. Yesterday I spoke with Shane Pearson, head of the BEA unit that acquired Fuego earlier this year and turned it into AquaLogic BPM Suite. At the time of the acquisition, a number of commentators (including me) noted the incongruity of making a non-SOA BPMS the centerpiece of BEA's strategic SOA platform. Since then, it has become clearer that AquaLogic is not (yet) a "platform" but really more of a "brand" that distinguishes the company's broader SOA initiative from WebLogic, its J2EE platform. There is, for example, a highly rated AquaLogic ESB and service registry, but these are in a different division from the one that houses BPM and portal (ex-Plumtree). Today, AquaLogic BPM mostly stands on its own -- without SOA -- but the company is beginning to build better connections to the ESB and registry, so that customers who want to step up to BPM-on-SOA can do so easily.
Facilitating such a step up is more market education than tools and technology. IT architects in the SOA world still have no idea what BPM is, and they still don't know what they don't know. Process owners on the business side don't really know what SOA is, although they've heard it's good. They just want to improve business performance, however it gets done. This is why BEA -- along with IBM, Oracle, SAP, webMethods, and Cordys... -- has to better articulate the integration, what it means, how to do it. So far, only BEA appears to be gearing up for this task.
In more concrete terms, here's how Shane explains it. Let's say as part of a business process you need to retrieve a customer record in SAP. With AquaLogic BPM 5.5 (i.e., the original Fuego product), you can directly introspect the SAP system, select the right BAPI, catalog it as a process component, and invoke it as a component method directly from the process. That's "direct integration" -- not SOA. It's quick and easy.
But in a global enterprise, as BPM projects that need to interact with SAP proliferate, having each one implement its own direct integration in this way becomes hard to manage. This is where SOA comes in. Probably BAPI is too low a level for the integration; it's not a "business service." Probably better to support asynchronous connection with reliable delivery and consistent fault handling. Probably better to leverage centralized service governance so that all consumers of the service use the approved current version. Instead of directly introspecting SAP, AquaLogic BPM looks in the service registry, and binds to that service. If deployed over an ESB, what the process invokes is a proxy endpoint that hides all of the data transformation and other "mediation services" performed by the bus. This is all SOA infrastructure; the process designer doesn't have to think about it.
In AquaLogic BPM 5.7, coming up fairly soon, there will be a bit tighter linkage between BPM and the AquaLogic service registry, but a lot of this you can already do today. And probably you can do it with almost any BPMS that can consume web services with just about any SOA registry and ESB. When you can and when you can't, what makes BPM, ESBs, and registries either hard or easy to glue together -- those are stories that neither BPM nor SOA vendors are yet telling. I don't understand it yet myself, but I'm going to try to do so.
In the meantime, you can read all about how AquaLogic BPM 5.5 works in the 2006 BPMS Report series, available for free download from BPM Institute.
Update: New information added by Shane:
Current State (AquaLogic BPM 5.5)
- AquaLogic Service Bus (ALSB) includes support for UDDI and provides a pre-built UDDI taxonomy for AquaLogic Service Registry (ALSR). In-depth understanding of all the ALSB proxy service types is NOT required. ALSB supported services published to AL Service Registry are reusable saving time that would otherwise need to be spent designing, building and testing.
- The integration between ALSB and ALSR is bi-directional. AquaLogic Service Bus proxy services can be auto-published to the service registry. Business services can be imported from the registry to be used in an AquaLogic Service Bus proxy service. Notifications are generated when business service changes in UDDI, and needs to re-synchronize with ALSB.
- AL BPM interoperates with ALSB or ALSR since it can directly import external services for use in business process flows. Using the AquaLogic Service Bus and/or AquaLogic Service Registry makes the implementation more robust since any changes to underlying IT systems do not have to impact the interfaces used in the business process. It also provides a separate level of control and governance outside of the AL BPM suite, which is an example of the value provided from using BPM with a service-oriented architecture.