Effectively Reuse Solutions
Introduction
I can not go much further than 20 years back in my experience, but I believe reuse has been a hot topic in computer science since the beginning — perhaps even before the first computer was created.
But why aren’t we all reusing all the time?
To answer this question, let’s first set a common ground looking at some reasons and examples for reuse.
The obvious reason is time and money — reusing can tremendously improve development and delivery times for multiple projects. If something can be leveraged, it potentially will speed up the business growth/transformation, save time and investments, have less cost of ownership, among other benefits.
Some common reuse examples include:
- Components shared library that were part of your reference architecture
- Service Oriented Architecture (SOA) which was created to be the ultimate reuse solution
- Microservices architecture to be a better version of all the above
- Entire business process where there is just a need to expand the capacity or capabilities
These are good examples that we can easily see in our teams, but not across them, and that’s what I want to explore in this article.
As a problem solver, let’s start looking at the root causes preventing reuse in the real world, then talk about ways to tackle them.
The real world
Often, the reason to turn to reuse starts with the thinking, “we can start from that existing service”, “we could lift & shift that solution”, or “let’s build on top of those microservices”, though this is naively planned. The reason I say naive is because, in most cases, the suggestion comes without having a minimum impact evaluation — being the effort/time to make it happen, the modifications and/or limitations the solution brings, the architecture readiness for reuse, etc. — and very often it is not even considered as part of the decision making process.
Adding to that, we believe that the reusable element is available, and we have the in-house know-how, so why is it that reuse isn’t happening more? Below I share some possible reasons, based on my experience.
The business team
“I heard we will leverage that solution. Great! Let me get a closer look… Hmm, this is not exactly what I had in mind, so we need to adapt here, there, and there, and…”
The reuse mindset isn’t the same in everyone: people may have different interpretations of what reuse is. They really want to collect the reuse benefits, but they aren’t necessarily flexible to accept existing limitations. Also, they don’t expect anything less than perfect, so no intermediary solution would ever be good enough. And this becomes a great challenge because the “required” customizations usually demands significant effort, resulting in time and cost impact.
At the end of the day, business and IT need to agree on the reuse benefits (especially when it comes to risk, time, and total cost of ownership — TCO) versus the flexibility they expect or demand.
The current solution “owner”
“This is my code, my product. If you want to reuse, go ahead but don’t touch my code.”
Development teams and/or solution owners develop a special relationship with their products and they do not want to lose the control. Naturally, they are also concerned of other people messing up the quality, roadmap, standards, performance, etc. Some genuine and good, but not always calibrated, intention. This can go from not being prepared for (or allowing the costs of) a new workload all the way to not having any readiness (or even intention) to allow source code forks or new features to be pushed to it.
The development team
“That solution was not built with the latest architectural standards and I want to use that new framework, which is very productive (and fun).”
The team assuming the leveraged solution often does not like the idea of working on a “legacy system” and wants to create their own, believing it would be better written, under control (same feeling of the “current owner” team), etc.
Another fear is not having the possibility of knowing better what that black box does, when connecting to services not designed for reuse.
The champion
Another possible reason to prevent reuse is the recognition. “If someone else is leveraging my solution and does a better job, he/she will be promoted, not me.”
This is very realistic (never verbalized) because most organizations have no incentive for promoting the reuse for both, whoever is creating a solution and the ones trying to leverage any existing one.
The real result
With these strong opposed forces in place, there is no reuse done the right way. What really happens is teams “copying & pasting” some source code or even disregarding it completely with some shallow excuse that it would not fit in the required time/scope/cost/etc.
In that scenario, most of the benefits of the reuse is lost as we can see next.
Note: If you are sharing an entire business process, most of the problems listed above may not exist — you are mainly focused on having the right personnel and budget to support and expand the business. But if you need to adjust your capabilities, then you may benefit from what is covered next.
So how do we actually reuse? That’s what I’m bringing in the Part 2 of this article.
