There are always trade offs to be made when you're dealing with keeping your application portfolio up-to-date. You always have several options, whether it be modernization through migration/refactoring or by a sort of "transformative leap". The presence and type of technical debt you have present in your system will dictate how you are able to modernize your application portfolio.
If you start to think about the manner in which technical debt manifests itself you will realize that the presence of technical debt is the difference between whatever is a state of the art application design and your ability to adapt your current offering to that new standard. Below figure 1 to illustrates this:
There are three approaches to managing the technology gap and your technical debt as shown in figure 2: refactoring, code migration, and transformation. Refactoring can be used to fix those small non-functional requirements, whereas large non-functional (and some functional) requirements can be aided through modernizing code and updating your infrastructure. Finally, resolving large non-functional and functional requirements can be done by abandoning your old code and transforming your applications.
While it may seem that refactoring and code migration/modernization is doing the job of keeping your technical debt in check, you will reach a point where continuos refactoring won't be able to account for the acceleration of the technology curve. Your ability to keep up will decrease with the fast growth of that technology curve as shown in figure 2.
So what happens once you can't keep up with the speed of growth of the technology curve?
You will start the process of hectically refactoring to try and modernize your code. The more you start to fall behind and frantically try to refactor your code, you may feel pressure from stakeholders to buy an off-the-shelf software option. This will be due to the fact that non-technical stakeholders will believe that since you can't keep up with building modernized software now that a build option cannot be feasible at all. This will spur a manic attempt to try and find the trade-offs between a build or buy strategy - and what you will discover is that the same issues of the technology curve gap illustrated in figure 1 plague the software vendor community. You cannot escape the issues of technical debt and adoption of new technology simply by buying new software.
This leads you to the point where continuous refactoring may very well keep close to the best-in-class applications but will always leave you behind having state-of-the-art applications. Eventually in order to keep up you cannot simply refactor, you will need to continuously migrate and transform your code. This means that when you release a new application you will need to immediately start a new project to refactor and modernize that application you just built and released in order for it to continue to be relevant. Incremental steps to maintenance will no longer be adequate. You will have to constantly build and abandon technologies as they fall behind the technology curve.
But this does not mean that you should throw your hands up and give up trying to manage your technical debt, code, or applications. It simply means that you need to adapt to a new "software development paradigm" in order to stay in the game. This post simply demonstrates the necessity of this sort of adaptability in a critical manner.
To read the full post visit here.