The lifetimes of custom business systems seem to be getting shorter. One reason for this is the rapidly evolving technology world, which gives frequent new opportunities for business development. The decision to create a new system is often driven by limitations of an existing system that negatively affect or threaten a business’s growth. This is especially the case when competitors have already developed new technologies.
There are also cases when the decision to change an existing system is dictated only by technology trends. For example, if an existing system is based on the web services architecture, it may be rewritten to a more popular microservice architecture with a newer platform and better frameworks. Usually, such a decision would be influenced by non-functional requirements like improved performance, increased frequency and flexibility of releases, and reduced runtime errors.
Is it worth rewriting an existing system in this example? Let’s analyze it based on the tangible criteria.
ROI
Building a new system is a huge undertaking that requires resources and many months of commitment. In the example above, the cost of resources and the cost of shifting resources from other projects are disproportionately high compared with profits. Additionally, if the new system is built only on technical requirements, it may not be able to address new business challenges without substantial efforts. This could result in a considerable loss.
ROI
Building a new system is a huge undertaking that requires resources and many months of commitment. In the example above, the cost of resources and the cost of shifting resources from other projects are disproportionately high compared with profits. Additionally, if the new system is built only on technical requirements, it may not be able to address new business challenges without substantial efforts. This could result in a considerable loss.
ROI
Building a new system is a huge undertaking that requires resources and many months of commitment. In the example above, the cost of resources and the cost of shifting resources from other projects are disproportionately high compared with profits. Additionally, if the new system is built only on technical requirements, it may not be able to address new business challenges without substantial efforts. This could result in a considerable loss.
In summary, it is typically not worth rewriting an existing system based on requirements driven only by technology trends. Low ROI results in such projects being low priority and high risk. But what if a system has performance issues, scalability issues, or other non-functional requirements?
First, all requirements should be added to the backlog and an initial analysis should be performed to determine the cost of a possible solution, ROI, and priority compared to other backlog items. In some cases, the full scope of non-functional requirements cannot be determined. For example, fixing a highly visible performance issue often reveals another one. Performance should be improved on an ongoing basis; tasks should be added to the backlog based on results of a completed optimization in a previous iteration. With this approach, the tasks can be executed by dedicating 20% of the team’s time (velocity).
So – when is it worth rewriting an existing system?
It is worth creating a new system if key business requirements cannot be implemented in the current system, or if the old technology significantly increases the cost and/or time of implementing the requirements. It is important to gather the key business requirements to make good design decisions, such as choosing the architecture, technologies, and platform. However, it is essential not to invest too much in a project whose lifetime will likely be shorter than expected.
In conclusion, we would like to share a summary of the approach we took to help a client who planned to rewrite a critical business system to address performance issues. The project goal was to improve performance by rewriting the system using the newest technology stack. Fortunately, we were aware of this plan because the client was going to involve our consultants in the project. Instead of starting the new project, we convinced the client to take a different approach. We helped resolve the performance problems by going through cycles of analysis/investigation, development/performance fix, and release that were aligned with the current system development Scrum interactions. Finally, we improved the system performance by 40%, which was almost what the client aimed to achieve in the planned rewrite project. Due to this improvement, the client had time to analyze the business requirements for the future system, make intelligent design decisions, and beat their competition.
+1 (888)
413 3806