Service reuse if often mentioned as an important aspect of SOA. Many people cite it as a way to measure SOA success. For example, Eric Roch:
Certainly if you were measuring SOA success, and you should of course, then an obvious measure is service reuse. A friendly competition between development teams that achieve the most reuse would be a great way to publicize and encourage service creation and reuse.
Reuse is very much a part of SOA. It's part of the simplicity of SOA, and in linking services together to solve an end-to-end business problem or process.
As mentioned above, when looking to measure the success of SOA, the amount of service reuse is frequently used as a metric.
Service reuse is both a feature and a benefit of service-oriented architecture (SOA).
However, it's never quite that simple and since the early days others have been suggesting that service reuse either isn't important at all or certainly shouldn't be considered the main driving force behind SOA. As Dave Chappell put it back in 2006:
Creating services that can be reused requires predicting the future… how can a service’s creators accurately guess what future applications will need? The ‘If-you-build-it-they-will-come’ approach is tough to turn into real reuse.
Now Burton's Richard Watson has entered the debate, suggesting that "reusability is always overpromised" and that developers, users and decision makers should not become fixated on service reuse. As he puts it:
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.
He suggests that it may be possible to break this down into an equation to calculate reuse and savings over time. But of course you would also need to factor in deployment and application specific criteria. According to Richard, what we should be looking at is the value of the service, and reuse is only a small part of that. As he goes on to say:
[...] 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".
Object reuse was often touted as a major benefit of object-orientation, but frequently the reality failed to live up to the theory. Eventually people stopped using this as a way of detracting from OO and focus on the other tangible benefits it brought (and continues to bring). Maybe service reuse is going in the same direction?