Revolutionary purge?

SOA is "one of those perfectly mind-numbing expressions that defies even a modicum of consistent definition, sounds important, and gives everyone the freedom to do it 'their way," argues BPM Group chief analyst Terry Schurter. "What an incredible waste of time, money and energy." Ouch...

Recognizing that he is far out on a limb on this one (defying analysts, entrepreneurs and all the other techno-barnums), Schurter proceeds to keep jumping up and down. As he sees it, "SOA expenditures will in many cases push important expenditures onto the backburner while they fiercely consume limited resources on a one way track to zero ROI."

He finds the absence of ROI-based business cases for SOA particularly offensive. "The reality is that SOA expenditures are not being tied to ROI, results are not clearly defined and metrics to measure ROI are not even seriously being discussed," he writes. "SOA is taking on the mantra of Nike, and as the SOA virus spreads to more and more businesses, corporate halls have begun echoing with the ominous tones of 'just do it.'"

Well, okay. Fair enough. It's hard to argue with the proposition that we are poised torapidly blow a lot of money on activities we hardly understand. We've proved in recent years we know how to do that.

Schurteracknowledges that service-oriented interoperability, interaction and integration is where we are all headed. He just isn't buying the view that SOA -- an architectural perspective, more than anything -- is the way to get there.

Here's where the argument gets a little shakier. He reaches into his own bag of tricks and tells us the answer is, drumroll please, a BPMS. That's right. Yet another "perfectly mind-numbing" acronym. Actually, the term is business process management system and Mr. Schurter comes to us from -- surprise, surprise -- BPMG.org.

As he explains it, "there must be the means for managing the connection points, oh and workflow. There must also be the means to handle SOA 'compliant' services and the many non-SOA services likely to be in place already. Even if the SOA approach does take into consideration these issues, the picture should now be forming that this is a BPMS function...because BPM software already has all of these capabilities built-in."

As I see it, there's merit to this view. But it doesn't necessarily follow that BPMS -- a software category, primarily -- should displace SOA -- a design philosophy,for the most part-- on the march to the "service revolution." No revolutionary purges are necessary.

Nordoes it follow, from my view, that SOA zealots will all be "plagued with problems, missed deadlines and scope creep," whileBPMS leaders "will have a completely manageable system, fully deployed on time and in budget with complete visibility into the system on an enterprise wide scale."

Can't we all just get along? The BPM and SOA movements have a unifying goal, as I see it. We both can endeavor to drive new process- and service-oriented thinking deep into the heart of the enterprise -- and, yes, overthrow the established order. We should, at least, wait until after the revolution to kill each other. Just ask Uncle Joe (Stalin that is, not McKendrick).