Back in its hey day, one of the benefits of object-orientation was supposed to be the ability to reuse objects between developers, projects, even companies. To a degree that did happen, but never to the level that proponents originally hoped. Within SOA, service reuse is once again something that is pushed as a benefit to developers but has it also failed to materialize? Obviously it is probably still too early in the SOA adoption path to be certain. However, as this recent report points out, there are many pitfalls and roadblocks to achieving a good return on your investment from service reuse. One of the greatest is the a close cousin of the Not Invented Here Syndrome:
... the human tendency to want to have something of our own as opposed to sharing someone else's. After all, we all learned to share in kindergarten, but we didn't like it then, and we don't like it now! If your own team builds a Service, it's bound to do just what you want, while if you share one from elsewhere in the enterprise, then all bets are off.As the authors point out, one important way to address this problem is through effective governance and establishing reuse policies. However, unless these policies are strictly enforced (which has its own set of associated problems), making service reuse a reality within an organization can still be difficult. Persuading people that someone else really did do a better job can often be a challenge. That's why the the authors describe their idea of introducing a competitive environment for services, which may also lead to improved implementation quality. Think of it like Darwinian evolution for software components: only the fittest will survive.
Encourage different provider teams within the enterprise to create competitive Service implementations, and then allow the users who wish to consume those Services to shop for and choose the implementations that best meet their needs. Furthermore, provide for a bona fide payment for the provider teams' troubles, either in the form of chargebacks to the teams' departments, or even better, bonuses to the team members themselves.Obviously such a radical shift isn't without its problems. Can an organization really afford to have internal competition between co-operative groups? How many organizations can afford to implement the same service multiple times, only to have one or more of those implementations eventually die off? However, the authors do point out that this isn't a general solution and should probably only be used in environments where overlapping efforts are already the normal practice. But then what is the optimal number of teams to have in order for this to work?
Too many would clearly not be cost effective, but only one or even two such teams will be more likely to produce Services that are lower in quality overall than if there are at least three competing efforts. The ROI question then becomes how to measure the value of the better quality Services, not just taken individually, but also in terms of the impact competition will have on Service quality over time.Obviously another problem is discovering these competing services. Hopefully registry/repository solutions will be able to play an important role here. Unfortunately there is no standard way in which to compare services. How can a developer or application determine that two services are identical or sufficiently so that one can be used instead of the other? Furthermore, competition works well (both for the supplier and the users) when there's feedback, so the report authors suggest that perhaps some form of rating system would be useful. However, once again there are no easy solutions for complex problems and it remains to be seen as to whether service reuse will be the success it should be, or if it will be consigned to software evolution history as yet another Dodo.