Derek Miers called my attention over the weekend to two posts from the SOA blogosphere suggesting “bad blood” between BPM and SOA, framing it as the latest proxy war in an age-old struggle between business and IT.  I suppose Derek, who doesn’t blog himself (yet), wanted me to point out how ridiculous this is (or at least embarrass myself trying).  Anyway, I’m taking the bait.

The original cherry bomb was thrown by Christoper Koch in CIO Magazine’s blog, who described BPM vs SOA as “a new front developing in the war between business and IT,” and Joe McKendrick on ZDNet quickly poured gasoline on the flames.   Koch tries to set himself above the fray but tips his hand by centering the discussion on business’s frustration with IT’s lack of agility and concluding that SOA is more likely to foster agility than anything he sees from the BPM camp.  Thus, like most discussions of BPM from the SOA world, he gets a few facts right but generally misses the point.

Agility is important, and SOA is all about agility, but agility is really IT’s concern and not the central focus of business executives, nor is dealing with change the key objective of BPM.  Better aligning processes with business goals; making processes faster, more efficient, and more reliably compliant with policies and best practices; making business performance more visible even when the process crosses organizational or system boundaries, and more actionable in real time… these are just as important as agility to business.

Koch’s ephiphany came at a recent BPM conference, where it dawned on him that “veterans of the

[failed] business reengineering battle have… adopted BPM as their weapon of choice in gaining control of processes.”  In contrast, at IT conferences, “SOA is all people talk about. SOA is the way that IT will enable the business to change its processes. But of course, SOA almost completely focuses on IT and integration rather than process.”  He should add, but doesn’t, that process is about more than business integration.  It’s also about improving human work, and as even the integration-centric BPM software vendors are now discovering, this is where the most energy is coming from in the BPM market today.

Yes it’s true, BPM people and SOA people are concerned about mostly different things, but they are hardly opposing armies facing off with guns blazing.  As a veteran of BPM conferences myself, I can vouch for the fact that the keynoting class there does tend to put forth a generally anti-technology message, but I think more directed against vendors of BPM software than at IT architects laying the groundwork for SOA.

The grain of truth buried in this pseudo-war is IT’s discomfort with the BPM notion that implementation of business process solutions can and should be, at least in part, driven by models created by “the business,” the so-called top-down approach.  Some in IT would rather take a few years to roll out a complete SOA infrastructure before thinking about orchestrating a few services to solve business problems.  For some reason, they don’t understand BPM’s top-down model-initiated approach can actually accelerate the SOA rollout by fostering business-IT alignment with concrete performance metrics, and encouraging an iterative approach to the production implementation.

Assuming Koch does speak for at least a segment of the IT community, my take-away from all this is that BPM software vendors need to address IT’s concern that BPM is “unsafe” technology.  So far their message has mainly addressed business values and concerns, and while they give frequent lip service to SOA, they haven’t really addressed how BPM can help IT in its transition to SOA. 

BPM and SOA are natural allies, not enemies.  While outrageous headlines and trumped-up issues are the staple of the blogosphere, this is one we can do without.