Is there bad blood between BPM and SOA?

In recent Weblogs, I have discussed the "top-down" versus "bottom-up" debate going on around SOA implementations. Some say SOA should evolve from the ranks on an incremental basis, while others say only a well-planned enterprise effort can make SOA deliver as promised. I have also talked about the perception that IT needs better alignment with the business.

'For better or worse, the only advancements that have been made in enterprise process change have been technology based.'

One industry watcher says that the only improvements we've seen to date over the past two decades are a result of bottom-up developments; in particular, changes driven by the technology side of the house.

This comes to the surface when looking at the convergence between business process management and SOA . On face value, BPM would seem to be a clear mandate for service-oriented architecture. SOA involves the same methodologies as process management, in that processes are broken down to granular levels in the pursuit of better transparency and agility for the business. The standardized service interfaces of SOA, in turn, break open data silos across the organization help deliver a single view of the truth to decision makers.

However, CIO Magazine's Chris Koch says there are some, well, issues to be worked out before we see a lot of SOA-BPM convergence. In a recent post, he calls BPM versus SOA "a new front developing in the war between business and IT."

It's bad enough there appears to be friction between these two methodologies; why a 'war' of all things? Koch says the bad blood extends back to the 1980s, when business process reengineering came into vogue, but would-be reengineers found their grandiose schemes blocked by fairly rigid computer systems.

"The black belts [of Six Sigma] chopped madly at the blocks of big iron and came away with nothing but sore hands."  

The next BPM foray came in the form of enterprise software packages, an effort to standardize processes across entire industry groups. "CEOs reasoned that if they couldn't change processes with pen and paper, they'd use the canned processes inside ERP systems to do it," says Koch. But "rationalizing the IT architecture, while certainly important, doesn't address the fundamental war cry of the business: We want to control and change our processes ourselves!"

Now, this ongoing process war is aligning behind two technology concepts -- BPM and SOA, Koch says. The BPM folks come from the business side, and the SOA folks come from the technology side. However, he holds out new hope, but emphatically states that SOA (and the technology side) have the best chances of driving real change in the business at this point:

"Now that both sides have a technology weapon, I'm more hopeful than I have been in a long time. That's because for better or worse, the only advancements that have been made in enterprise process change have been technology based. The Internet, integration middleware and enterprise software, for all their flaws, have built more cross-functional sharing of business processes than any Six Sigma process redesign effort. IT is better equipped and more motivated to support enterprise sharing than business people. A controversial assertion, I know, but research has shown that IT has had a more long-lasting effect on enterprise sharing than any of those organizational realignments that the business side tries every few years. There's just too much politics and competitiveness among business leaders and business units--as perhaps there should be--to build enterprise cooperation unless it is supported by IT."

There you have it. Koch says real change will come from the technology side of the business. "I know, I know, tools don't substitute for leadership and alignment and all that, but if you look back at the last 20 years, the tools have made more of a difference than the humans."