

Maximizing reusability of SOA services

Reusability is often seen as the "holy grail" of software development – everyone wants it but nobody gets it. As such, maximizing reuse is a very tricky challenge.

How can I maximize the reusability of services in my organization?

Reusability is often seen as the "holy grail" of software development – everyone wants it but nobody gets it. As such, maximizing reuse is a very tricky challenge. Many organizations take the "build it and they will come" approach, which is effectively unplanned reuse. As teams build solutions, an inventory of the constituent components and services is built up. New solutions are expected to look to the inventory to see what things exist before building something new.

In reality, the deck is stacked against this approach. Because all development is always scoped at the project level, the chances of having similar decisions around granularity, capability decomposition, interfaces are very slim. On top of this, the structure of the organization is not built to share, it is built to deliver projects. If a service needs to be modified, who is going to do it? If it is the new project team, how are they going to make sure they don't impact the first solution that built the original service? In a nutshell, there's a lot more to reuse than just building a service. 

There are improvements that can be made to this, such as announcing new services as they are identified and seeking input on the requirements from outside the project, but that will still not maximize reuse. If the initial project decomposes things differently than another project, some areas for potential reuse may never even come up for discussion.

In order to maximize reuse, you have to have a plan of attack. This is where enterprise architects and domain architects must earn their keep. Their job is to think broader than any one project. They are the ones who have to identify the areas for potential reuse to provide a framework for project teams to target their efforts. The preferred approach for this is through capability maps. Capability maps express things in terms of business functionality, providing a framework for project teams to use in defining their solution architectures, but also for identifying areas for reuse. 

To determine targets for reuse, the capability domains must be paired up with the business goals and organizational structure. This is a very important step, because just because something can be reused doesn't mean it should be. By its very nature, reuse has a higher degree of overhead, since there are teams outside of the normal project structure that are involved. In the early stages, this overhead may have an impact on delivery until things get streamlined.

If time to delivery is critical to meeting the strategic business goals, then the right amount of reuse for your organization may be in very well defined areas, typically in domains very low in the stack. If lowering operational costs is more important, then it may make sense to identify more areas and establish new service teams to obtain the maximum amount of cost savings possible. Whatever the goals are, however, it cannot be done without having a framework to make those decisions, and that framework is the capability map. 

Dig Deeper on Topics Archive

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.