Not to beat the dead horse, but during a discussion the other day with a fellow SOA cohort, I came to a realization for the reason SOA & BPM get inextricably tied together in some individual’s thoughts. I’ve written and blogged before on how SOA & BPM have very different goals. SOA is about application rationalization via a service metaphor and BPM is about business process analysis and optimization. The fact that they are discussed in the same breath leads one to believe that they are inherently related, when in fact they are not.

That said, as one performs a top-down analysis of their business as part of a BPM initiative, they are going to discover they need a framework to assist in implementing new business processes that cut across departmental and other organizational boundaries. Clearly, one of the greatest areas for improvement within in an organization is across these organizational boundaries because process improvement tended to be an intra-departmental exercise. When the process needed to cross an organizational boundary, the political, geographic, technological, etc. hurdles led to inefficient crossings.

Historically, SOA and BPM rose in popularity at or around the same time. SOA, led primarily by technological practitioners, responded to the needs of BPM practitioners for a framework to capture and implement newly-designed and efficient cross-organizational business processes with technology. However, for BPM, technology is the least of the problems. Indeed, BPM’s biggest issues are political and geographic in nature. A process that needs to cross continents or rely on participation of a department that is resistant to change pose a far greater problem to process optimization than not having a web service available to invoke.

Still, there is seems to be a natural gravitation toward SOA as providing the necessary framework to capture and implement new cross-organizational business processes. Most likely it is the service façade that allows various business functions to be exposed as technological assets accessible over common Internet protocols. After all, what better way to create a business process that crosses organizational boundaries than tapping directly into the data and systems that support those sub-organizational areas?

However, it’s important to note that SOA should not be viewed as the nail for BPM’s hammer, as is all too popular a notion today. It is not an SOA if you decided to wrap a few legacy systems with web services so that you could easily build out an automated business process. That is just part of your BPMS effort.

This entanglement of SOA and BPM into a single effort is fraught with problems and failure. Each initiative should be undertaken separately and with definitive goals that do not list each other as one of the outcomes. If as part of the rationalization that SOA provides, there happens to be some services exposed that simplify the implementation of a particular business process, then that would certainly be a slam-dunk. However, SOA and BPM each have their own metrics of success and their own barriers to success. Combining them into one, well, the words “boiling the ocean” comes to mind.