BPMS vendors love to throw a bone to SOA, and if you weren’t paying attention you might even think that BPM on SOA was real.  I’ve written at length about how BPM and SOA aren’t enemies but natural allies, but they are allies with distinctly different goals and aspirations and mental models of the world.  Kind of like America and France.

Following his post on the subject, I’ve been having a side conversation with Jesper Joergensen of BEA about what real BPM on SOA would look like.  I admit I’m still trying to figure it out.  Here’s where I am so far.

Let’s start by acknowledging the inherent Mars/Venus-ness of BPM and SOA.  For example:

  • BPM is top-down.  It starts with the end-to-end process in mind.  SOA is bottom-up.  It starts by factoring the world into atoms and molecules of reuse — business services — that can be consumed by any number of processes or applications.
  • BPM is business-driven.  A “model” created by the business drives the implementation.  SOA is IT-driven.  Technical architects define the scope of business services based on their own notions of “abstraction” rather than business need.
  • In BPM, success is measured by business metrics and KPIs at the end-to-end process level.  In SOA, success is measured by architecture, logical consistency, ease of integration.  Performance goals do not extend beyond the individual service level.
  • BPM is project-oriented.  The goal is solving a real business problem today.  SOA is enterprise infrastructure-oriented.  The goal is creating a foundation for solving many business problems a few years down the road.
  • In BPM, what is reused is the process model, i.e. the “abstract” design of a process fragment.  It is inherently transparent — you see its steps and their individual performance parameters.  In SOA, what is reused is the service implementation.  It is inherently opaque, defined simply by its interface.  Its internal steps and performance parameters are invisible, except for an overall SLA for the service as a whole.
  • In BPM, a business process is inherently hierarchical, composed of nested and chained orchestrations.  In SOA, services are inherently independent.  An end-to-end process is more likely to be implemented as a spaghetti-like SCA assembly than a nested hierarchy of BPEL orchestrations.
  • In BPM suites based on service orchestration, process activities are bound to service endpoints.  In SOA (supposedly), orchestrated services are supposed to be abstract, with connection and mapping to endpoints mediated by an ESB.  The ability to swap out endpoints performing the same abstract service is the effective definition of loose coupling.  I don’t know of any BPMS offerings oriented to this mode of orchestration.

If you accept most of the above, you might ask why try to save this marriage anyway?  But the goals of BPM and SOA are not opposed, just different.  Bringing them together is mostly a question of timing.  BPM, trying to solve real business problems today, starts by acknowledging that the refactoring of the enterprise into “business services” — macro-scale units of reuse — doesn’t yet exist, so the best approach for now is simply to incorporate service-oriented middleware here and there — mostly in application integration — in the BPMS. 

In SOA, BPEL orchestration in reality is mostly used to assemble business services out of low-level APIs.  They call that “BPM,” even though it’s not what the business means by that term.  Eventually, there will be enough of those business services in the registry that BPM can orchestrate them in end-to-end business processes.  That’s the end state that makes bringing BPM and SOA together worthwhile.  We’re just not quite there yet.

So let’s wind the clock forward a bit to a time when, in some organizations at least, the set of defined, built, deployed, registered, and governed business services is significant enough to form the basis of key business processes.  What would a BPMS layered on that infrastructure look like?

First, it seems that in such a world, BPM and SOA likely each have their own enterprise repository/registry.  The SOA one would hold opaque service implementations – IT assets – bound to physical endpoints, SLAs, and perhaps other “contractual” aspects of the provided service.  These services are not “abstract,” but real services offered by real service providers.  The BPM one would hold transparent process models – specifications of business services – in which activities can be mapped to services in the SOA repository to create an executable instance of process model.  Processes (including process fragments, or abstract business services) in the BPM repository could be reused throughout the enterprise to provide standardization and consistency with best practices, mapping model activities to different service providers in each instance.

Second, I believe that services in the SOA repository will generally not include human tasks, even though business services that include human tasks (payInvoice and things of that nature) are frequently described within the SOA vision.  Unless the human interaction component is very simple and a minor fraction of the functionality, services that include human tasks should be represented within the BPM repository instead.  One reason is you want to retain the transparency, i.e visibility of internal state, as well as ability to configure and analyze human resources to optimize performance.  Conceivably one could add such attributes to the SOA repository, but they would no longer describe “services” as meant by SOA.  Another reason is that the individuals and groups mapped to task performer roles are going to be different in each reuse of the model.  This notion of reuse is fundamentally different from that of a single web service being consumed by multiple applications or processes across the enterprise.  The latter is more about outsourcing than reuse.

In my mind’s eye, the distinguishing characteristic of a BPMS layered on SOA would be a design environment that can:

  • retrieve and copy process fragments from the BPM repository, and assemble them within larger end-to-end processes
  • search the SOA repository for available business services as a guide to scoping activities in the process model
  • bind process activities to services in the SOA repository, via proxies defined by SOA infrastructure (e.g. ESB).  Any mapping from the service interface to backend systems providing the service is handled by the ESB and mappings within the SOA domain; BPM doesn’t have to think about it.
  • turn newly created processes and process fragments into “abstract business services” and store them as models in the BPM repository.
  • leverage SLA, cost, and other service properties from the SOA registry in BPM performance analysis (simulation, BAM, etc.)

In Part 2 we’ll talk about how this differs from the way current “SOA-based” BPMSs work, and how it might evolve.