Tying together BPM and SOA technology

BrainStorm has been a hot topic this week for the BPM and SOA crowd. Sandy Kemsley blogged about the BPMS vendor panel (which didn't appear to engage her unfortunately), hosted by Bruce Silver. I would have loved to attend the event, which I couldn't (being sat in my office in Boston at the time). But I was interested to weigh in around some thoughts around BPM and the relationship with SOA technology, a discussion that came up with the panel. This is where my coworker Steve McDonald and I mind-melded a bit.

I have been working through releasing an SOA edition of the process, content and case management product I manage, and in doing so have observed many pitfalls that face human-centric BPM products in an SOA technology world. My view is that a BPMS can get caught in the trap of becoming another component of the SOA infrastructure. The SOA view of BPM and process execution demands that a process engine interacts with other systems and executes branched business processes and not a lot else. The BPM gets sucked down into the SOA infrastructure, lost in a Bermuda triangle of web service acronym checklists. Steve constantly reminds me that this is a waste of the capabilities of a BPM and content based product.

BPM software customers agree that the purpose of a BPMS is to control real business processes and enable effective management and improvement of those processes. I believe that processes that have typically been implemented with BPM are readily identifiable as business services and should be treated as such. For example, large insurance companies that have not yet embraced SOA may run multiple variations of an otherwise identical property claims process in a BPM application for different business units. This claims process is a high level business service that could be reused, and the BPMS should enable that. Within this top level process there are services that should also be reusable, for example Fraud Investigation. The BPMS should clearly identify the services, allowing them to be extracted from the core process and reused, moved elsewhere in the organization (or even outsourced). Treating traditional process components as loosely couple services provides this flexibility, but to achieve this the BPMS must understand SOA and be able to interact with the infrastructure.

To achieve this, the BPMS must have some strong SOA capabilities and link back to the infrastructure, without becoming overwhelmed by it. So I think that three requirements are:

• A BPMS must be able to consume services published in service registries, and implemented through ESBs, custom applications and other BPM processes
• A BPMS must be able to host its processes as services for reuse across the organization
• A BPMS must provide visibility across services and processes that extend the boundaries of its own process model. Pulling loosely couple services into end-to-end business processes demands stronger oversight and visibility of performance than monolithic business processes executed by a single system
  

The infrastructure of SOA is important to an organization implementing services and business processes. BPMS must consume the services of more technical components than ever before, should host process based services, and be an enabler for exposing process (and content) services that common data centric SOA components do not handle well.

I think its possible that integration of the BPMS into specific SOA platforms as a complete vendor stack leads to artificially tightly integrated architectures. SOA infrastructure relies on web service standards, and SOA as a methodology demands loose coupling of services and identification of components with separate roles. Integration of platforms into a proprietary stack leads the IT team back to a monolithic architecture, and away from the true objectives of SOA. BPMS and SOA platforms should play together, not be tied together.

---
I'd like to thank Steve for voicing some of our combined opinions around this on the panel. He certainly seemed quite excited by the chance to talk about this common theme in a way that obviously, and unashamedly, reflects the strengths of the products we both work with.

Technorati tags: BPM SOA brainstorm