Creating a service oriented architecture is like dieting: as much as it's tempting to shell out money for the latest promising gimmick, the reality is that reaching the goal requires a significant lifestyle change.
"Weight loss is a very much like SOA in that it's a discipline," says Ron Schmelzer, a senior analyst at research firm ZapThink. "It's more important to change the behaviour, if you want to change the outcome, than it is to buy something new."
An SOA is a platform for building modular, reusable application components that can be called and combined without the integration pains of past development efforts. Pursuing an SOA approach promises to make new and existing IT assets more flexible - and therefore more easily used in different, innovative ways.
But like the any diet fad, the SOA approach is vulnerable to backlash from unfulfilled expectations. For example, reuse of services is a key element of an SOA, but it can be very difficult to achieve if teams are unwilling to share applications, says David Chappell, principal of research and consulting firm Chappell & Associates.
Companies can try exerting pressure from top management, or implementing a charge-back policy whereby internal customers pay the internal service suppliers, or selling the idea of reuse, because it's best for the company as a whole - but none of these approaches is easy, Chappell says. "I've talked to organizations whose SOA efforts stopped dead because they couldn't deal with this problem."
Another roadblock to SOA adoption is the tendency for companies to gravitate to familiar technologies.
A lot of people are pinning their hopes on the emerging category of enterprise service bus (ESB) products, many of which are little more than old-school messaging brokers with new labels, Schmelzer says. Adding more of the same, familiar infrastructure products just continues the cycle of technology rip-and-replace, he says.
"People are really overestimating the ability for these ESB products to deliver a service-oriented architecture for them." On the other hand, the importance of tools that support a change in development behaviour - such as process-modelling tools, meta data management and registry products - are underestimated, Schmelzer says.
Equally important to the success of SOA is understanding when it's appropriate. Zeroing in on a specific business need can help companies make decisions about how much of their existing applications to service-enable, says Theo Beack, chief SOA architect at Software. In many cases, exposing 20 or 30 percent of the functionality of an existing legacy application as a Web service can yield the most benefit. "That's where the sweet spot lies," Beack says.
It's also important to understand that not every new application should be built in a service-oriented style. It takes more effort to design, create and secure a service-oriented application than a traditional multi-tier application, and not all applications are likely to repay the expense, Chappell says.
"An application that's meant to be used only by a relatively small group in an organization might not be worth the expense of being built in a service-oriented fashion," he says.
Key to avoiding wasted resources is having the right people behind an SOA effort. A lot of good developers make lousy architects, Schmelzer says. Companies today are hiring architects that are measured against business goals - such as how quickly a service will return value to the business - not traditional development goals.
"If we can get it right, the emergence of the architect class will be a pretty significant transformation for the IT industry."