The conventional wisdom is that while SOA can support new levels of agility for large businesses, the key benefit to push when selling SOA to upper management is reuse. "Build once, use many times." In a recent article directed towards the insurance industry -- an IT-dependent sector if there ever was one -- SOA is portrayed as an opportunity to exploit legacy capabilities in new ways "at a reasonable cost and with minimal disruption" -- through reuse of those capabilities as Web services. This is a typical view that is expressed over and over in the high-tech media.
But ... although reuse seems to make a lot of sense because it cuts programming hours and eliminates redundancy, it is a practice that also introduces risks. For starters, replacing some function that appears in a dozen applications across the enterprise -- currency conversion, for example -- with a single service means creating a single point of failure. That's not necessarily good.
Also, there are times when legacy code doesn't work very well as a service, particularly when it wasn't written with reuse in mind in the first place. Sometimes, even code specifically created for reuse can have unintended consequences once deployed.
If you create a service, test it in the real world and practice good governance, you're probably okay. But to think that reusing services is an automatically successful "slam dunk" idea is a mistake.