Tuesday, January 29, 2008

SOA + BPM = Killer Combination

Kurt's recent posting prompted me to put down here what I've been putting off for a while: my thoughts on BPM and SOA. Hopefully it's apparent to everyone that BPM != SOA: they solve different problems. However, that does not mean they cannot compliment each other. The recent work on combining jBPM with JBossESB should illustrate that, but let's go further.

One of the key aspects of SOA is about agility: the ability to react more quickly to changes in the way IT systems need to be deployed and used, as well as being able to leverage existing IT investments. At this level agility is something that is definitely a concern of T-Shirt And Sandle Man, i.e., IT folks and not Men In Suits, i.e., business folks, which is primarily where BPM resides. Where BPM works well is in ensuring that business goals and efficiently aligned with how they are translated into processes, making those processes more reliable, faster and compliant with the businesses policies and practices. Fairly obviously, for business folks, these are just as important as IT agility.

SOA and BPM do not compete with one another: they are natural compliments. A good combination of SOI (Service Oriented Infrastructure) and BPM will make it natural to orchestrate services (or more likely tasks) as second nature within the deployment and not as some bolt-on which is there simply for compliance reasons. I think the combination of SOA and BPM is a "killer app" because:

  • BPM promotes a model-based approach to task definitions, which, if used right, should ensure that what the business wants is what they get. Importantly it's defined by the business folks and not by the infrastructure. It encourages a top-down approach to service orchestration and requirements: you don't develop what you don't need. I know this sounds pretty obvious, but you'd be surprised!

  • BPM and tooling are natural allies, as they are with SOA.

Remember that SOA is not a product: it does not come in a shrink-wrapped box. So you shouldn't think that it is simply an ESB or some other technology. It is not purely a technology driven initiative. A good SOI will allow the right people in an organisation to take ownership of the components (technology and business) that are important to them. This is one of the reasons why loosely coupled systems work. SOA does not belong to a single group of people (e.g., the typical developer), but to the business as a whole. That's why SOA+BPM work so well together: it is a natural fit.