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 the recent Interop conference in Las Vegas. Howard was asked to give a kind of State of the Union address on SOA.
"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 organisations 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 modernisation, unified communications, business intelligence and various other important tasks, Howard noted.
But very often, IT departments implement an 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.
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 change in mind-set, 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 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. Re-branding old products and claiming they are SOA-compatible is pretty common, Howard said. In fact, it's not in the vendors' interests 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," he said.