By some estimations, the average lifespan of an enterprise application is about a decade. Forty years after the start of the personal computing revolution, a large portion of enterprise development is replacing legacy systems. The reasons for replacement vary, but two big reasons are the system cannot support the current scale and the maintainability and reliability are low after a decade of patches. In any case, the decision is made to retire the old system and build a new one.
Given the decision to replace the system, it should be clear that the new needs are different from the needs when the system was originally developed. Yet many product managers will start the replacement process with an in depth inventory of the system's current functionality. Why does this happen?
The first set of reasons are generally associated with risk aversion, and the line of thinking starts with some simple, immediate facts. The existing system is serving a purpose for users or other systems. The new system will need to support these people or systems. And, we will need these other people or systems to switch from the existing system to the new system.
The solution to these problems is generally found to be some level of backwards compatibility. The reasoning goes: we don't want to break other systems, create a cascade of required changes in dependent systems, or retrain users. Therefore, we should require backwards compatibility with the current functionality and add on the new, desired functionality. This seems rational; we'll come back to it.
It's also worth considering that while the stated reason may be risk aversion, which might be proactive at some level, there is the reality that this approach could be driven by laziness. It's much easier to inventory existing functionality than to design better, more effective functionality. In an enterprise environment, it's easy to underestimate the impact of lack of engagement and imagination.
Let's consider a different set of facts, but this time let's consider opportunity instead of risk aversion. During the years that the existing product has been in place, the business has changed, the competition has changed, and the users have changed.
Also, technology has changed. There are more architectural choices from monoliths to micro services. There are new cloud services that are available to solve issues of availability and scalability. There are choices in API design between REST and GraphQL. There is better UX practices and more environments to run on.
Given all this new potential, why not build from the perspective of what competitive advantage the new system should provide and what features would entice users to adopt the new system? When you offer someone something that will make their life better, they will solve their own problems to adopt the new system. When you provide a system that reduces costs or generates revenue, the financial burden related to switching systems will be reduced or eliminated.
Which brings us back to the risk aversion mindset. When people adopt the risk aversion strategy, they rarely include the risk missed opportunities, yet it's opportunities that drive the business forward, the opportunity to do things better, faster, or cheaper. Build for opportunity.