The Risks of Reuse

Loraine Lawson

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.

Add Comment      Leave a comment on this blog post
Apr 3, 2007 7:54 AM Frank Millar Frank Millar  says:
As is true of so many dimensions of SOA, reuse is a consideration that requires analysis, experience, and begs for evolution. These are just some of the reasons that Mike's pointing to risks are appropriately cautionary.Nevertheless, it would seem beneficial to stay clear about the context here of solid benefits relating to reuse. One example: Once a specific SOA connection is completed, the possibility arises of inexpensively porting that success to similar occurrences disseminated in partitioned environments throughout an enterprise.My example, of course, is a different perspective on reuse than offered by Mike, but just as valid nonetheless.A conclusion here might be that this topic underscores another reason to have an enterprise architect involved with SOA projects. Reply

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.