If we put off maintaining our vehicles, it is not too long before they fail on us, likely long before their expected usual life. Software systems are no different; with regular maintenance, a system can age gracefully and provide value for decades. The challenge with managing software systems is the difficulty with determining the health of a system. Organizations must balance numerous priorities and if the current state of their software systems is satisfactory, resources will be diverted away from maintenance. This is totally normal; however, if ignored too long, it sets up organizations for what I will call the “Replacement Trap”.
A conversation regarding software maintenance requires an overview of technical debt. Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now, instead of using a better approach that would take longer. Technical debt is repaid by spending development time on refactoring the project at the cost of adding new features or functionality. Technical debt can be viewed similarly to financial debt, if not repaid it will accrue interest, making future repayment more difficult. To combat technical debt, software maintenance can come in different forms: corrective, adaptive, preventative, and perfective (more info here).
Technical debt has one more dimension worth mentioning: institutional knowledge. It takes time and energy for an individual to learn the inner workings and nuances of a software system and this knowledge requires maintenance too. Without maintenance, knowledge fades away, leaves the organization, or retires. Think of any task that you do every once and awhile: there is always some friction relearning how things worked. This friction scales exponentially with the complexity of the system. It is not uncommon for a piece of technology to be installed and operate untouched for years. When technical debt accumulates, like interest on debt, there comes a point where the organization faces technical bankruptcy and, in many cases, will not know it.
When maintenance is put off for too long, there comes a point when the software systems the organization uses fall into an unhealthy state. Warning signs could be that the organization is still using instances of software that have been deprecated by the vendor; changes are large, cumbersome, and time consuming; analysis on next steps takes weeks/months; a heavy governance layer is required to oversee changes; it has been a long time since new functionality has been introduced; continuous dependence on external vendors; or, the backlog (if it exists) is difficult to organize and manage.
Organizations in this situation have set themselves up for the replacement trap. A breaking point is met, and the only clear and logical answer is to replace the current system with something new. If your organization was not on top of maintaining its existing systems, it is unlikely that it has the institutional knowledge to map the features and functionality from the existing system to a new one. If communicating and coordinating between functional areas of your organization is challenging, imagine how hard it will be to have a successful implementation when giving an external vendor (who probably has little idea how your organization operates) incomplete and incorrect requirements. It is like ordering food in a different language at a hardware store. The patio furniture is lovely and the gas grill looks amazing, but all I wanted was a burger.
But isn’t modernization a good thing? Replacing legacy systems will reduce costs, increase agility, and provide our customers and staff with a better experience. At a high level before implementation starts, proposed replacements will always appear like they will be a great fit. “We need to replace our ERP system”, “this awesome vendor has an awesome ERP system”, “it is just an ERP system, what could go wrong?” Is it realistic to believe that how your organization envisions what an ERP system is, would be the same as a vendor creating a product that is targeted to many other organizations? How focused is the product to your industry? Are you coming from a custom implementation to a product that claims to be configurable for anyone? The greater the translation, the greater the implementation risk.
When organizations fall into the replacement trap, the replacement implementation runs the risk of turning into a trash fire. Results may vary but here are some examples: ballooning of scope and costs as understanding of the previous system is revealed, the new system is implemented but with diminished capabilities due to lack of resources for implementation, or the new system was hacked into place leaving the organization with the same pile of technical debt.
How to avoid the trap or get out of it? A well-maintained system evolves with the external environment, upgrades are planned not forced, and technical debt is understood and managed. For instance, a large part of our financial system still runs on COBOL (an excellent discussion on COBOL), a language originally released in 1959! However these systems have been well maintained and can continue to run for many more years. In many cases a replacement project and the subsequent maintenance is an order of magnitude larger than the previous maintenance budget of the legacy system, if the system has not been replaced, consider how the same resources for replacement could be deployed to pay down technical debt. Prioritize deprecated systems: fragile and insecure systems are disasters waiting to happen. Focus on development lead time, make work visible, limit the amount of work in progress at one time, reduce batch sizes, reduce the number of handoffs, identify constraints, and eliminate waste in the value stream. Develop a knowledge management strategy to build and retain working knowledge of the systems your organization uses and avoid single individual dependencies. Aggressively promote training and skill development of staff. Lastly, a digital transformation is not something that happens overnight, but is realized incrementally.