Savings from Reusing Services Oversold and Overpromised

Loraine Lawson

At one point, the big promise with service-oriented architecture was reuse. Everybody I talked to used Legos as an analogy for SOA. Just as you can reuse the same Lego pieces in various building projects, you could reuse services in different applications, which meant less custom code and a quicker deployment time.


These days, reuse seems to be going the way of the panda, which is to say it's not extinct like the dodo, but for all practical purposes might as well be. While you know reuse can and does exist, it's seldom encountered, either in the wild or in captivity. You certainly shouldn't expect it. Service reuse is just too hard, too high-maintenance, (again, like pandas), and too risky.


It was frustrating, frankly-especially since reuse had been used as a cost justification for SOA, and remains a popular metric.


But, it turns out, reuse as a cost justification may be a red herring anyway. (Apologies for the mixed metaphor.)


In a recent blog post, Richard Watson, an analyst for the Burton Group Application Platform Strategies, takes a skeptical look at calculating the savings from reusing services. Often, he notes, these savings are calculated based on a formula that looks something like this:


"Savings = Cost of Implementation - Cost of Integration
Savings = services * reuse * change
Savings = sum ( f (cost of integration at consumer, cost of change to service provider for new consumer) ) over #reuse, where f is 'some function of.'"


I couldn't help but note that the cost of integration comes into play in two of these formulas. And it looks good, right? But in reality, he explains, you won't see those savings in a concrete way:


Reuse savings are problematic because stated like this, as the client I spoke to says, "if I've saved all this money, where is it?" Of course, it's deferred expenses, but that doesn't sound quite so valuable. These formulae also overstate the value of reuse over time.


That's OK, because according to Watson, even unused services can add value in other ways, including being cheaper to maintain, improving security or compliance and reducing redundancies.

Add Comment      Leave a comment on this blog post
Jul 1, 2009 10:39 AM Loraine Lawson Loraine Lawson  says:

Another excellent piece on the same topic:

Jul 6, 2009 12:03 PM panzrwagn panzrwagn  says:

Every instance of reuse means, in addition to the requirements, development, and unit test costs, one less unit of data to manage, transmit, process and store. But wait - there's more: A unit of data requires test, dev, prod and DR facilities as well as storage, backup, archiving, network, data center physical plant, power and cooling for each instance. 

The reuse cost analyses I have seen only concern themselves with software costs. For every $100,000 in reusable code and direct business data, I would venture an educated guess that there are 10X that amount in supporting costs these analyses ignore.

Failing to take a full 360 view of the environment misses the big picture story: Utility drives efficiency and expediency drives cost.  And metrics with over 3 variables are ignored because it takes too much work in Excel, or involves asking people outside the tower for their inputs.

Jul 9, 2009 10:23 AM James Pepper James Pepper  says:

Another benefit of reuse is time-savings in development/deployment of new applications. Many applications could benefit from a set of common services like, user authentication, presentation layer, data validation, secure data submission, backend data management schemes, messaging, etc.  Once these have been developed and vetted, they can be reused to save a significant chunk of low-level development effort, thereby freeing developers to focus their attention on specific business needs/functionality as they develop new applications. -Jim


Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.