BearingPoint Says SOA Can Be Costly, Hard To Maintain

Financial services firms that have implemented services under a service-oriented architecture are finding these services can be more expensive, less reliable, and harder to maintain than standalone applications, said Sajay Sethunath, the chief architect for BearingPoint's financial services consulting business.

His conclusions should be taken as a warning sign to other industry sectors that have approached SOA as a simple pathway to the future. Financial services firms, with their heavy reliance on transaction processing, have tended to be early adopters of successful database and application architectures. If they're having trouble with SOA, then other industry sectors may face the same problems.

Many of Sethunath's views are summed up in a new BearingPoint report by Pete McEvoy, senior manager of BearingPoint's financial services architectural practice, that's about to be released. It's called, "Seven Years of SOA: So What?"

"One site built a journal-entry service for use by three lines of business. When they were done, only two businesses could use it," because the requirements hadn't been gathered carefully enough to allow the service to span the needs of all three, Sethunath said in an interview. SOA implementations are under pressure because of such shortcomings.

In the first phase of SOA enactment, technologists on the IT staff have tended to pick the low-hanging fruit and build services that they know will be used over and over again by several applications. But too often, the IT staff hasn't established a metric that shows how such effort leads to savings. What's worse, many didn't build a service that business users wanted, said Sethunath.

It costs more to build a reusable service -- up to 35% more -- than it costs to build one for single use because the reusable service must anticipate the environments and workflows that it will have to fit into, he said. Even when built for reuse, the available service may never find its anticipated users, and the investment that went into designing its general-purpose nature goes down the drain.

A rigorous method of determining what functionalities yield good reuse within the enterprise is required, but in the financial services firms that Sethunath has seen implementing SOA, "few firms have come up with objective decision criteria for doing so," the report states. This issue was cited in Information Week's early examination of SOA implementations.

And actually reusing services to leverage the initial investment can be hazardous to your systems' overall reliability, since the services are likely to run into unexpected conditions and combinations of software with which they must work.

"Many of the first services built comprise such low-level functionality that they are of little interest or use to the enterprise at large," the report states. Without business management involvement in the services under construction, "funding SOA on a large scale becomes a problem," the report concludes.

Finally, once a set of services is built, it needs "the equivalent of a commercial software company's product manager," Sethunath noted. Someone must decide when the services should be revised and how to manage the different versions. Without such governance, a large set of services, frequently revised, becomes an unpredictable conglomeration, threatening consistent systems uptime, he said.

Financial services firms are still working out the best governance methods, but if they devote time and attention to the issue, SOA can be managed, Sethunath said.