As an architect, deciding on the tech stack for a problem statement is a common challenge. A variation of this is when there are competing implementations of the same functionality in the same org and there is an obvious desire to combine the stacks for cost and maintenance. Let’s talk about a strategy based on first principles.
How do you decide to combine the tech stacks?
May be start enumerating the key capabilities in both stacks and determine the gaps. Choose one stack as the base and build the diff features to help onboard the other scenario. This works well when the domains are similar, or the functionalities are only a handful to reason over. To make things complicated you could imagine both domains growing fast in multiple axes in the coming future.
How do you make progress when the domains are separate and both the competing stacks have been in production for years?
You cannot start from the requirements because they are innumerable to reason over. Instead you start from the first principles. We’ve talked about Principles and Values at length earlier. The defining characteristic of a principle is that it is constant and acts as a set of constraints. We reduce the requirements into a mental model which represents the domain completely.
Next we start to reason over the mental model from a fundamentals perspective. Take the scale, performance, security, and reliability aspects of each domain. How does the mental model evolve to support all of these? The resulting diff would answer if at all the architectural mental models overlap and merge is the right solution.
Does overlap in functionality always imply merging the stacks?
A common mistake in these conversations is around scale. We have a stack which is built to scale handling 100K requests/s. Can we use it for a low volume/scale scenario? Even if it appears straightforward, the answer is it depends. Not always can we step down the scale keeping everything else constant. Beware of using a spaceship for inter-city travel.
Key takeaway: always step back to see the bigger picture, get a deep understanding of the domain and start from the first principles.