'Build once, use often' an SOA fantasy?

What's the greatest value in SOA? For many, it's the notion of build once, use often. Reuse is golden, in that a service component needs to be only designed and built once (but tested often), and be made usable across the enterprise. No more redundancy of development efforts; no more reinventing the wheel.

Christopher Koch, editor at CIO Magazine, however, says that industry expectations around the reuse concept have been far too optimistic. In a recent blog post, he observes that "some early stats that say only 10-30 percent of services are being reused," noting that "the predictions that people had about reusability aren't panning out."

What's going wrong, then?  Koch believes that "the rush to reuse tends to overlook the complexity of figuring out how to build these composite applications so that enough people in different divisions around the company can make use of the service you have designed." In other words, we tend to exist in heavily siloed organizations with stilted communications. Even in the age of SOA, services will still get built and thrown over the wall with no real input from intended potential end-users.

I agree with Koch that actual service reuse is still in the minority. In a survey I conducted for WebServices.Org last year, we explored the depth and breadth of service reuse across 1,000 enterprises, and found only 21 percent were at a stage in which they were actually sharing services across two or more business units.

Organization communications and politics are big obstacles, but the survey also told us that it was simply too early for many organizations to start thinking about proliferating services. Notably, the vast majority of sites only had up to five services in production. It isn't worth investing in mechanisms that can help proliferate services across the enterprise -- such as registries and repositories -- until an enterprise achieves some type of critical mass of services, usually about 20 or more.

Of course, development productivity is only one side of the coin; the enterprise needs to see advantages on the business end of SOA as well. The business agility benefits are even harder to document at this time, and this makes gaining initial sponsorship a job in and of itself. Koch quotes Jeff Gleason, director of IT strategies for TransAmerica Life Insurance Company: "I’ve heard this a hundred times, where a business sponsor said, 'Well, if you’re going to make me pay for creating this service the first time, you just blew away the cost benefit of my project, and it’s not going to get sponsored. And so I want you to go ahead and hard code it because I need that functionality.”

Koch observes that Gleason overcomes such objections by showing internal clients "how many times that potential service has been hard coded in the past, how much it is costing to support all the extractions and data storage feeds." However, Koch adds, Gleason also needs to know how other business units will want to use the proposed service. "That means understanding all their different processes and getting their permission to fiddle with their systems--which, according to Gleason, meant he needed the CEO to demand cooperation from the different business units."

In a previous post, I outlined the three stages of ROI seen from SOA, and I'll repeat them here. Note that reusability only comes in during phase 2 of an SOA evolution:

• Immediate ROI: A fairly quick return on the costs of integration, especially for large organizations with complex distributed environments, and a need for better integration will see benefits from simpler.  Easy to measure — calculate the money spent on consulting fees for tying two applications together.
• ROI a little bit later in the process: A savings in development time and planning because of the reusability of services across the enterprise.  A little more difficult to measure, but the savings will be evident in that much more can be done without having to hire new developers, or bring in extra consultants.
• Long-term ROI:  Greater agility for the business, since processes can be quickly broken down and rebuilt as business needs change.  However, this is difficult if not impossible to measure at this time, since few are at this point.