SOA failures traced to people, process issues

Most SOA efforts will fail spectacularly.

Those were the words Burton Group analyst Anne Thomas Manes told colleague Chris Howard when he asked her what one overriding message IT executives should hear about service-oriented architecture.

Howard, vice president and service director for Burton Group, was hoping for something more inspiring to tell the audience during a session he led Tuesday at the Software 2008 portion of Interop Las Vegas. Howard was asked to give a kind of State of the Union address on SOA, a much-hyped approach to building IT systems that are flexible and capable of reusing old assets.

"The state of the union of SOA right now is there's some fatigue set in," Howard said, noting that when he recently asked an audience of 300 people whether their SOA efforts were going well, only a half dozen responded positively.

The problem's not technology, Howard said. People and processes are at the heart of what's wrong with SOA as it currently exists in enterprises.

SOA connects applications across a network via a common communications protocol, allowing organizations to reuse old software, often with the help of Web services. 

There are certainly many examples of enterprises succeeding with SOA, building services that can be shared across business units, and lowering long-term expenses. SOA can make it easier to do compliance reporting, software-as-a-service, legacy modernization, unified communications, business intelligence, and various other important tasks, Howard noted.

But very often, IT departments implement a SOA program that may be technically proficient but doesn't meet the needs of business users, Howard said, noting that Burton Group is researching SOA successes and failures through interviews with IT pros and business executives at dozens of clients.

Business executives often conclude that IT pros exaggerate predictions of reusability or underestimate project cost, Howard said. IT professionals are generally bad at presenting the business case for SOA, and need to get better at explaining the long-term benefits in cost and flexibility to CEOs, he said. This is difficult, given that businesses tend to focus on immediate rather than long-term cost savings, and point solutions rather than strategic goals.

SOA requires a "significant paradigm shift," Howard said. One good approach is to start with a small project that can have a positive impact for a relatively large number of business users, and then advertise the success, he said.

Many SOA problems are caused simply by IT and business units not working with each other, or business units refusing to share resources. If you're running a bank, it makes sense for commercial and consumer banking departments to share processes. But end-users may rebel when they're asked to share, according to Howard.

"We can spend a lot of time and energy making all this shared stuff that makes IT more efficient, but it doesn't solve business problems," he said.

A good SOA project requires leadership from a C-level executive who can spur changes in a company's culture, Howard said. "We need to get better at trusting each other as human beings. None of this is really about technology," he said.

Vendors are also contributing to SOA problems. Rebranding old products and claiming they are SOA-compatible is pretty common, Howard said. In fact, it's not in the vendors' interest to have products that are fully compatible with their competitors' technology, he noted.

It's important to remember that "SOA is not a thing," Howard said. "You cannot buy it. It's not shrink-wrapped. It's a state of mind. It's a way of building things."