X
Business

Analyst: IT departments are sabotaging SOA

Here's a switch: businesspeople get SOA, but IT fails to see its full potential
Written by Joe McKendrick, Contributing Writer

Conventional wisdom dictates that tech-challenged business executives that also happen to hold the purse strings stand in the way of SOA proliferation across enterprises. However, ZapThink's Ron Schmelzer lays the blame for SOA inertia right at the doorstep of the folks that are supposed to be its prime advocates -- IT departments.

Here's a switch: businesspeople get SOA, but IT fails to see its full potential

Ron says business executives, for the most part, seem to get SOA. They realize the benefits of an agile, reusable, and loosely coupled architecture.

"Even when a business has approved the investment of significant sums in their SOA projects, ZapThink has found that in many cases, their own IT organization can and will sabotage those efforts, slowing the SOA drive to a crawl."

Yikes! Ron is suggesting, then, that technologists tend to be too focused on the weeds of SOA and don't see the big picture. Is it because we're asking too much of IT; telling it to 'go forth and be a change agent for the enterprise, or else'?

Ron observes that "too many people in the IT organization conceive SOA as a technology concept only, and as such think of SOA as just a set of technologies and infrastructure for exposing, securing, running, and managing Services. With those technology blinders on, these IT practitioners see SOA as nothing more than Web services and standardized middleware."

Not only that, but technologists don't even like the LEGO-block analogy for SOA, he adds. The business folks like the analogy because it puts SOA in easy-to-grasp terms.

It's worth noting that agree or disagree with Ron on this point, the tone of this commentary -- as well as many other analysis -- is that resistance to SOA is coming from somewhere. Few analysts, commentators or pundits seem to argue the point that SOA is facing resistance; it's just a question of where most of it is coming from. 

Back to Ron's contention that IT itself is the stubborn holdout. Why do technologists fail to see SOA as a business initiative? "Successful SOA adoption requires a cultural shift in the way IT is done," Ron points out. "The service-oriented movement to agility and loose coupling demands a shift from traditional, waterfall styles of development (design-build-test-deploy-manage) to iterative approaches to continuous service modeling."

Plus, managing SOA calls for business skills that many IT people simply have not been trained for -- such as budgeting and governance. As Ron puts it: "Some reason, 'why bother with this new SOA thing when at least you understand how the old tightly-coupled integration thing works?'"

My own observation is that technical folks like tinkering with new technologies and gadgets, and usually have moved on to the next big thing long before businesspeople catch on to the previous big thing.

Todd Biske weighed in on Ron's analysis, noting that often, there are issues with both IT and the business that get in the way of effective SOA. And, he nails it in observing that a forward-looking corporate culture -- engendered by enlightened management -- is more likely to spawn successful initiatives such as SOA, as well as many other things:

"The organizations that are claiming success with SOA probably had a culture that already had IT and business working together at a higher level. Therefore, I would expect that a business that realizes 'the benefits of an agile, reusable, and loosely coupled architecture (even if they don’t call it that)' has a mature Enterprise Architecture practice, with IT having a seat at the strategic planning table. If that’s the case, it would be even more surprising to find a huge gap between IT management and architecture and the actual IT execution."

A well-managed business that leads with best practices -- and taps the entrepreneurial energy of its employees -- is not likely to have a dysfunctional or reactionary IT department. These are the organizations that will see SOA through successfully.

It's that paradox again: organizations that could really use SOA thinking the most -- those that are hidebound, highly political, and impose a 9-to-5 mentality on their workforces -- are not likely to be pushing for SOA anytime soon.

Ron is correct that convincing the business is not enough, and for SOA to succeed and percolate across the enterprise, companies also "need to address the latent resistance, hostility, resentment, and fear in the IT organization that will effectively prevent SOA adoption and success."

However, the IT organization is only as good as the business that signs its paychecks. As Todd puts it: "If the business doesn’t think strategically, which you’d think would be required in order to understand the benefits of an agile, reusable, and loosely coupled architecture, how can can IT be expected to think strategically?"

Editorial standards