Top Five Strategies to Consider When You Can’t Re-Write your Legacy Systems
June 10, 2022
Summary
A system rewrite may not be viable either because the timing isn’t right or because it’s a matter of business case justification. But when a system rewrite is off the table, CI/CD can be utilized to streamline the code review process and continuously monitor the system’s health. You can even go a step further by rewriting sub-features to reduce technical debt, deploy microservices to better support customers and finally make a move towards a reporting solution such as a data lake to innovate on analytical requirements when the inevitable rewrite finally takes place. Adopting these strategies can help iron out the kinks in your system and restore system stability while parallelly making it fool proof against the legacy demon.
Read More..
Reading Time: 4minutes
As discussed in our series of articles on legacy software, a system rewrite may not always be feasible. Sometimes it’s a matter of timing, other times it’s a matter of business case justification. Whatever the reasoning may be, we highlight the top five strategies to consider when a system rewrite is not on the table. These strategies help restore system stability as much as possible while enhancing the system for future enhancements and upgrades.
100% CI/CD
The fact that Continuous Integration and Continuous Delivery/Deployment (CI/CD) made it to the top of the list often makes some people nervous, at least initially. However, once we realize that most legacy systems already have a mix of semi-automated deployments and integrations, the pressure comes down a bit. While a 100% CI/CD strategy takes time to develop, it streamlines the branching and merging of code and promotes a centralized code review process that is key to eliminating unforced errors. Furthermore, CI/CD also provides a smoother refresh from staging to production environments, helping to manage hotfix releases with greater ease.
System Health Monitoring
The famous saying goes, “You can’t improve what you don’t measure.” As it relates to software systems, we can’t improve let alone fix what we’re not measuring and monitoring. As one would expect, legacy systems come with a slew of disparate technologies and code snippets that may not mesh well together. Therefore, a standardized logging and monitoring system is important to notify of potential problems. To start, leaders should establish System Health Monitoring KPIs that are important to reduce negative customer impact. The logging should be centralized, with clear monitoring of “hot paths” or processes that consume a high amount of execution time. There should also be automated logging of repetitive errors, which could point to deeper problems within the system. And lastly, a cross-functional team of product and engineering leaders should hold a biweekly review of these KPIs and system health logs. Ideally, these KPIs are updated every one to two quarters with a clear path progressing towards greater system performance over time.
Targeted Sub-Feature Re-Writes
As software leaders know all too well, legacy systems inherently carry a load of technical debt. While an entire rewrite of the system is out of the question, and perhaps even a rewrite of a feature as well, starting with a smaller part of a major feature is often warranted. Just as the saying goes not to bite off more than you can chew, we start out with smaller chunks of sub-features to optimize. This mindset may not yield a large amount of progress initially, but over time can add up to be meaningful to both customers and engineering teams alike. We’ve helped several enterprise customers in this area, and they have witnessed significant returns in system stability and predictability over a period of nine to twelve months.
Micro Services for New Features
While developing new features on top of a legacy system is difficult and risky, taking a microservice strategy could be viable in continual efforts to support customers. By decoupling business logic and interdependencies of monolithic system architecture, microservices can be considered as a subset of features or modules that make up the overall system. Furthermore, a phased implementation can help avoid disturbances to the system as each microservice is optimized for its own use cases. This approach reduces the further technical debt on the legacy system and ultimately these microservices can be reused when the inevitable rewrite takes place.
Data and Analytics Strategy
Legacy systems normally possess a wide range of reporting features or functionalities. Adding any new features and changes would cascade to reporting too. Strategizing analytical and reporting to a data lake (centralized repository) and moving towards an out-of-box reporting solution will enable the businesses to enhance and innovate on analytical requirements. This design facilitates future rewrites and potential integrations too.
Conclusion
At some point down the line, a system rewrite may be inevitable. But until then, these strategies can help stabilize even the most convoluted systems and provide continued value to end customers. Once you determine that a rewrite is better than the continual maintenance of an outdated system, there are several key prerequisites to tackle before the decision is made. A proper transition with new development frameworks is necessary to ensure system rewrites only occur on rare occasions going forward.
At some point of time or other a legacy system would need a re-write or a series of sub-feature rewrites. As the above strategies enable us to stabilize the current legacy system, we have covered various aspects to consider when you have taken a decision to re-write. Refer to that post here.
