There's a lot of talk about the viability of the CIO role, but sometimes, a CIO can make all the difference.

And, as it turns out, this is particularly true with SOA implementations.

A new CIO coming on board during a business and IT reorganization often made the difference between SOA failure and SOA success, according to Anne Thomas Manes, an analyst with the Burton Group who recently studied real-world SOA implementations.

Manes presented her findings during this year's Burton Group Catalyst Conference. SearchSOA.com covered the conference, which also included a testimonial about Cigna Group Insurance's struggle with SOA. According to the article, Cigna Architecture Director Chad Roberts said the company's SOA started four years ago with a "technical focus mostly based on integration," but within two years, the SOA implementation had faltered. One big problem: It was seen as "an IT thing."

It took a new CIO to move SOA from "an IT thing" to a "business-enabling thing."

Of course, successful SOA doesn't require a change of the CIO guard. The article enumerates other factors named by Manes, including starting agile or iterative development methodologies. But I couldn't help but notice that most of the factors found in successful SOA implementations would depend on strong, business-focused leadership from the CIO.

Likewise, Manes' list of SOA failure factors traces back to too much focus on technology and too little change in the IT culture. Unfortunately, the Burton Group uncovered more failures and missed opportunities than success stories: 50 percent of the 20 companies surveyed reported a complete failure rate, with an additional 30 percent describing SOA as "neither successful nor wholly failed."

I can't say I was surprised. During a recent interview, Ron Schmelzer of ZapThink told me that business users have a much better understanding of what SOA is than technologists.

"...technologists are the wrong place to have this conversation. SOA is enterprise architecture, SOA is not standards-based integration. Web services is standards-based integration. ... The irony of this is the business fully understands the SOA perspective."

Techies want to boil SOA down to its parts, which is understandable, since they have to build it. But along the way, they're missing the big picture. Schmelzer compared it to blogging. If you're just talking about technology, blogging is just a bunch of Web pages, and yet, blogging is so much more. Business users embraced blogging as a new communications tool, but to many in IT, blogs are just so many Web pages.

Certainly, SOA can help IT with problems like integration. In fact, many companies are moving to SOA for just this reason and integration might even offer you a way of demonstrating an ROI for SOA. And I don't think there's anything wrong with that - so far as it goes.

But as Manes' research shows and analysts -- including Schmelzer and David Linthicum - have repeatedly said, it's only a small part of the SOA picture.

The sad part is, SOA really could be the key to delivering the responsive, business-enabling IT that CIOs keep promising business users. In a recent post, Linthicum put it bluntly:

"Summary: SOA is not tactical. You need to consider the people, and you need to consider the business. SOA is holistic and systemic to the business. SOA is not a project, it's a journey. SOA is not integration, it's architecture. SOA is about business agility, not governance or other technology."

Increasingly, I'm starting to believe the real question isn't "How do you define SOA" or even "Is SOA worth pursuing," but whether IT can get out of its own way to deliver on SOA's potential. For that to happen, IT will need a CIO who understands SOA and can lead the charge for change.