A few years ago there was fairly clear blue water between BPM and SOA in the minds of both users and vendors. Each camp promoted significant benefits from their offerings and, although there was a recognized touch point between the two, each was happy to exist with or without the other. However, time has not been kind to the purists on both sides. Pure BPM solutions are delivering some benefits in enabling business functions to understand and partially automate the key business processes for those areas. Typically this is done around existing applications and infrastructure, as proposing significant IT change as part of the business case for BPM is normally the kiss of death for the project as Not Invented Here (NIH!) Syndrome is displayed by IT.

Similarly, IT-sponsored SOA initiatives have hit a plateau of benefit after having turned all their systems into services. Once the (normally low) re-use figures and (slightly lower) maintenance costs have been squared with the investment needed, the savings can look borderline, with little prospect of further value to be gained with SOA.

For those who don't believe me, I have come across two depressing examples of this in the last month with clients where IT has vetoed BPM tools as unnecessary. Coupled with a growing frustration by business leaders as to the lack of business improvement gained from their SOA investments, this is causing both approaches reducing credibility.

So whatever camp you are in, you will find that the promised real business benefits remain tantalizingly out of reach. With the cold wind of recession blowing around the world, businesses and their IT departments are being forced to do more with less. Increased spending in these areas is unlikely to be approved unless a solid business case and quick ROI are demonstrated.

Some clients, as well as vendors such as IBM, have spotted that there is significant synergy to be gained by getting BPM and SOA working together effectively. Their challenge is that the sponsors and champions of each approach will almost certainly differ, and may well have conflicting or misaligned objectives than can obscure the benefits of using both BPM and SOA to address business goals.

Spotting this synergy and working out an effective strategy to map the two together is where we see significant effort being expended by the smarter organizations. These companies see real value in connecting BPM and SOA through the increased flexibility gained by a deeper understanding of the key processes that define their business, along with the necessary services and application functionality required to deliver high quality customer service at minimum cost. Although these benefits are potentially significant, there are a number of potential hurdles to overcome:

Governance: Few companies have in place the end-to-end governance structures to ensure that the full lifecycle of business change is well controlled and managed across the business-IT divide. Too often SOA Governance is treated completely independently of the business Governance, Risk and Compliance (GRC) function, rather than aligned closely with business governance.

Language: Besides the issue of radically different vocabulary and architectural standards seen in the two camps, formalizing a communication medium that acts, as a two-way conduit for information has proved elusive for many. Our investigations have occasionally led us to recommend translation tables ("Rosetta Stones") to allow the two parties to communicate efficiently. For instance, defining the terms 'Service', "Activity", "Task" and "Process" can take significant political effort and time.

Interfaces: What BPM expects from its interface with SOA tends to differ from what SOA expects to be asked by a business process. Typically, a business process requires a high-level business service to deliver the information or transformation required. Most services are developed as relatively low-level Web Services that interact with the application, data and presentation layers of the infrastructure to pass back a string of data. The definition of the lower level process steps and the higher level (composite) services is key to bridging this gap.

Logic: Traditionally most logic associated with a business process was coded into the application programs that supported them, or held in the heads of the users. It has become increasing obvious that an organization gains most understanding and flexibility by abstracting the logic to its relevant level with the BPM and SOA stack. So at the process level, business policies, business rules and process workflow logic needs to be separated and managed independently of each other. Routing and transformation logic are best handled by the bus and broker technologies that exist in SOA and BPM stacks. Program and data logic should reside within the services and databases respectively.

None of these hurdles is insurmountable, but it does require willingness for the BPM and SOA groups to have both an ongoing meaningful dialog, and a business improvement approach that spans the traditional gap. Below is an example of a Process Improvement Roadmap that has successfully helped to bridge this gap. By working to align the business and technology tracks, the delivery of the combined BPM and SOA benefits should manifest itself as an integrated change program. Let me know if it works for you!

John is currently Head of Business Consulting at Alphacourt Limited. Prior to Alphacourt has worked for Gartner, along with several other IT and business consultancies. John has been presenting on application development and business process improvement for over 20 years, most recently focusing on making BPM and SOA work for organizations.
SOA Institute