Moore’s Law. I won’t bore you, but you need to learn to fish to manage your application portfolio going forward.
Not only is the speed of technological change impacting how quickly your applications fall into technical debt, but Government’s are unable to legislate ahead of new technologies such as driverless cars. For a great read on this latter point, check out Thomas L. Friedman’s book “Thank You for Being Late (An Optimist’s Guide to Thriving in the Age of Accelerations)’.
For the remainder of this post I’m leaning on, interpreting and extrapolating Rob Klopp’s CIO Review article on IT Modernization, Technology Acceleration and Continuous Transformation. Rob is CIO & Deputy Commissioner-Systems of the Social Security Administration.
Firstly, let’s look at the definition of technical debt.
Technical debt comprises both aging around non-functional requirements such as maintainability, extensibility etc., as well as an inability to match the functional requirements (required internally by the business and/or externally by customers).
Depending on the size and nature of this technical debt, there are several options in terms of how to manage it.
For a definition and normalization of terms, refer to our our recent post ‘Legacy Systems – What’s In A Name?’. Essentially what this figure is showing is that small amounts of technical debt (non-functional) can be met by refactoring; while larger amounts of (functional) technical debt require the application to be modernized, eliminated or replaced with a COTS alternative (but be aware that COTS products are equally likely to be suffering from their own technical debt over which you will have little control). The area in the middle offers up a range of alternatives including migration and simply upgrading the code (without touching the architecture).
In the past, our ability to manage technical debt has been somewhat static or discrete in nature. Meaning, in the last century, an application could take 20 to 30 years to move from the left of the chart to the right and decisions on how to manage that technical debt were discrete, fixed in time and, once taken, could be forgotten for another 20 years. Or so they thought.
Today, because of the pace of technological change, apps are incurring technical debt the minute they are launched (if not before) and the journey from low technical debt to high technical debt is probably no more than 5 years.
The answer is two-fold. Firstly, to move from the paradigm of discrete action to the continuous management of technical debt and, secondly, to embrace all that open source has to offer. Wherever your application sits today on the technical debt continuum, there is a ‘modernization’ alternative that will get you to the far left. Having done that the challenge is to stay there which is where a process of continuous modernization comes in.
The new paradigm of continuous modernization is one that Morphis already supports. Once an application is modernized (re-architected to a cloud-agnostic MVC architecture implemented in C#/.NET or J2EE/Java), we ship it to our clients with a low-code development framework for easy maintenance and continued enhancement of the application. Of course, there are no runtime dependencies on Morphis meaning our clients and their customers are free from any kind of ongoing royalty payments.
These low-code development frameworks can then be coupled with the functionality of our software intelligence tool, Kuscos, to enable continuous, intelligent code refactoring while maintaining industry or company-specific quality standards.
The second part of the answer is provided by the open source community. Adding functionality to a product using open source components has never been easier and enables the rapid enhancement of applications. Participating in the GitHub community, for example, is likely already a feature of most software development shops.
Of course, the integration of open source components requires a modernization approach that supports enhanced integration which, in turn, negates approaches such as the migration (lift and shift) of COBOL applications from the mainframe to new platform.
So, lots to think about, lots to do, and ever decreasing amounts of time to get it done. Contact us to help you begin your program of continuous modernization.