The Cost of Reuse
By michael.stamback on Aug 07, 2008
Could a 'not built here' attitude undermine the benefits that SOA has to offer? Is the web 2.0 generation creating a new breed of developer that embraces reuse above all else? These are tough questions that are difficult to answer. Since the term reuse began rearing its head years ago, there's always been a bit of resistance to reusing code that someone else created. In fact, lack of reuse is one of the leading causes for failing to realize the benefits SOA has to offer.
It's not that organizations aren't building enough services, it's that organizations aren't encouraging the creation of enough reusable services. With SOA, we're not just asking developers to reuse code...we're asking them to utilize shared services in their applications that they have no power to modify. That can be a little scary when you're used to having imminent domain over what you're creating. This fosters the 'not built here' mentality - the death sentence for reuse.
'Not built here' isn't something unique to SOA. It's a cultural issue. I've even seen it prevail within the engineering departments of some of the software vendors I've worked for. So how do you shift the culture so reuse is not just accepted, but desired? How do you establish a level of trust that reusing a service will not negatively impact your service level agreement to the business?
To address the cultural aspects of reuse, try attempting to encourage the creation of reusable services. Hold contests that reward teams for creating the most reusable/reused services or for utilizing the most reusable services within their applications. This can foster friendly competition amongst your development teams that not only makes it fun and rewarding for developers, but benefits the business by encouraging reuse.
There still needs to be a measure of trust, however. To accomplish this, create a more formal provisioning process that provides a structured way for negotiating terms of usage for reusing a service. Consumers and providers can negotiate contractual obligations, such as security entitlements and service level agreements, that guarantees the consumer a level of service provided and guarantees the provider the service will be utilized correctly. This accomplishes two things: 1) it establishes a level of trust between the consumer and provider and 2) it creates potential new revenue streams for lines of businesses while reducing operating costs.
Let me address that second point. When it comes to reuse, there tends to be an issue of burden of cost. Should division A carry the burden of maintenance costs for a service that is being reused by division B? Many times this can be what leads to discouragement of reuse. Creating a charge back model as part of the provisioning process can help to alleviate this concern.
Division B, however, may be hesitant to pay a cross charge for use of a service it does not own. However, analysis will show that the total cost of ownership is drastically reduced through reuse. Take a typical cost of implementation and add maintenance costs over time. Maintenance cost is an ongoing charge that can now be shared, saving you not only the implementation cost, but reducing the overall maintenance budget, freeing up funds to focus on new, value-added investments. Even though division B is paying for reuse of the service, total cost of ownership is still lower then building it themselves. While operational costs for division B are reduced, this also creates a potential new revenue stream for division A, especially if externalized in the form of cloud computing...but more on that later.
So will fostering a culture of reuse magically make SOA successful? No, not by itself, but it's important to consider, especially given the tangible and intangible benefits it can potentially provide.