Is reuse an idea that's too good to be true? The idea of "build once, use often" has a lot of appeal for enterprises, and, as discussed many times in this blogspace, the first and foremost return on investment to be gained from SOA.
There has been a lot of buzz and money flowing into governance and registry/repository technologies as of late, all premised on the idea that reuse (and, I should add, sharing) would soon be the way of enterprise solutions.
However, David Chappell (the .NET guru David Chappell, that is) pours some cold water on this happy-talk scenario, observing that the "reuse" concept didn't work too well with object-oriented programming, and isn't working too well with SOA, either. Writing in the latest issue of his newsletter, Opinari, Chappell says reuse of business objects failed, simply because "despite heroic efforts from many IT managers, architects, and developers, the cultural and business barriers to reuse were just too great." He says that everyone he's spoken with is struggling with the reuse issue with SOA, which raises questions about the fundamental value of SOA:
"I’ve spent much of the last two years flying around the world talking with people about SOA. What I’ve heard from virtually all of them is that reuse of business logic is nearly as tough with services as it is with objects. Even Gartner is now saying that you should expect to reuse only a fraction of your services, maybe just 20% of them. Yet if service reuse is so limited, how much value will SOA really provide? If an organization reuses only one in five of its services, why is it building the other four? The one that does get reused had better provide significant value to make up for the cost of the four that sit idle."
Chappell puts it this way: "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," he says. Plus, there are few, if any, organizational incentives to build a component that can be reused by other groups.
There are situations where reuse is working, Chappell points out. Integration is one such value point: "Anyone creating an application that must be accessed in different ways, such as by a JSP front end, a Windows Forms client, and a mobile device, might well find that building an application in a service-oriented style is an excellent idea. Letting these various clients access the application via common services will make life simpler for everybody."
For reuse to work, Chappell says, companies need a corporate culture conducive to the sharing of innovation across departments, with "top management support, strong commitment, and diligent effort." How many companies are fortunate enough to have such visionary management and corporate culture?
A few thoughts here: Converging trends and business necessity -- above and beyond the SOA "vision" itself -- may help drive, or even force, reuse. SOA is not springing from a vacuum, or even from the minds of starry-eyed idealists. It's becoming a necessary way of doing business, of dispersing technology solutions as cost-effectively as possible. And, ultimately, providing businesses new avenues for agility, freeing up processes from rigid systems.
The world within and around enterprise technology is changing. Technology is growing increasingly sophisticated, and IT departments overburdened. Enterprises no longer have the time or resources to field numerous technology silos -- those days are over. There's no time to keep reinventing wheels. Plus, to add another Gartner observation, many parts of the IT function are evolving directly into business units themselves. When it comes to future technology, it's all about the enterprise.