Blogger: Richard Watson
Measuring service reuse alone is not the right way to determine the value of a service. SOA advocates tend to fixate on service reuse, and fill business cases with return on investment calculations based on reuse projections.
"Reusability is always overpromised."
This is a comment from the CIO of a Fortune 500 company interviewed by Burton Group. It reflects the risk in fixating on reuse. The memory of his application architects claiming that reuse is virtually guaranteed by object-oriented design has not quite dimmed. Likewise, applying service oriented principles promotes reuse, but does not guarantee it. Reuse is a complex issue, as much cultural as technical. As Jeremy Meyer eloquently says [i]:
Reuse is about people and education, not just architecture ... The truth is that even the most beautiful, elegant and re-usable architecture, framework or system will only be re-used by people who: a) know it is there, b) know how to use it, and c) are convinced that it is better than doing it themselves.
A service may never be reused, but still be used to create value in other ways: by being adaptable and less costly to maintain, reducing redundancy, increasing security and compliance through consistent enforcement of policies, to name just a few other desirable outcomes. Exclusive focus on reuse blinds us to these other outcomes.
I've had some great conversations recently with clients about calculating reuse. It's a tricky calculation. Most reuse savings formulae look something like these:
Savings = Cost of Implementation - Cost of Integration
or
Savings = services * reuse * change
or
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".
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. Some kind of decay function is needed to take account of a discount in the 'Cost of Implementation' value. I'm out of college too long and not crazy enough to attempt the math for that decay function, I just know it exists. I'm not convinced it's always a decay function either. If a service can take advantage of network effects then its reuse benefit over time actually rises. And unlike radioactive decay, the value of the service can be refreshed occasionally, say when a changes to reporting regulations dictate a different set of rules and the changes required can be made in an isolated place instead of across the board. But that gets us back to the value of service "use" not "reuse".
[i] Jeremy Meyer. In "97 things every software architect should know", ed. Richard Monson-Haefel. Sebastopol: CA: O'Reilly. 2009.
Comments