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
Related Q&A from Todd Biske
The emergence of the stack brings up an important question: Are app servers dead? Contributor Todd Biske examines the future of the app server in a ... Continue Reading
Everyone has a different viewpoint on SOA, but three key differences between SOA and microservices architectures can help you determine which is best... Continue Reading
Why do we need mircoservices architecture? How can we benefit from it? Continue Reading