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.
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.