Technical debt. Business value. Non-functional requirements. Extensibility. Functional requirements. Business processes. Skills shortages. Systems of record. Systems of differentiation. New market entrants. Cloud. Hybrid cloud. Containerization. Refactoring. Non-invasive modernization. And on…

No, I’m not keyword stuffing, nor do I think the end is nigh for Gartner (just to clear that up), but I have spent most of today trying to fit the myriad options for dealing with legacy systems and the vast number of ‘modernization’ drivers into a concise, easy-to-use map that you can use to figure out your next options.

My previous favorite was Gartner’s TIME model (hence the title, get it?)

But this is a quadrant approach to what is not even a 2-D problem; it’s 3-D at best and most likely n-D. It’s not even static, but now requires a solution that is fluid and, itself, capable of adapting over time.

I love quadrants but simply couldn’t map todays legacy modernization landscape to TIME. Starting with ‘Technical Condition’. I understand great and poor, but how does that map against technical debt which is usually a measure of the non-functional requirements of software (performance, maintainability etc.) and then the functional requirements? It’s easier to see three segments: failing to meet small non-functional requirements; failing to meet large non-functional requirements; and failing to meet significant functional requirements. A legacy system in each segment will require its own approach to fix the problems.

‘Business Value’ is clearer although not applicable for a software vendor whose product is considered outdated and in need of a refresh. All of their products are important, right? It’s more of a measure for back-end systems and maps to Gartner’s model for application portfolio analysis (Pace-layers) which identifies systems of record (standard business functionality) and systems of differentiation (systems that help the business differentiate themselves in their market). We used the system of differentiation to explain why Aurizon’s switch to SAP HANA failed recently.

The third dimension that can’t be ignored is the ‘why’ the legacy system needs refreshing/killing/modernizing. Common drivers are: lack of functionality; security issues; skills shortages; cost; and poor user experience. Which of these (and it’s often multiple) is the driver to having to take action with the legacy system, and then where the system fits in terms of technical condition and business value.

Compounding the issue is the speed of technical change. Not only is this not slowing, it’s growing (exponentially). While we’re concerned today about legacy systems from decades ago (generally), today’s new systems will be outdated in double quick time and any attempt at modernizing systems needs to be an ongoing process and is no longer a one-time effort.

We don’t have the map worked out yet but we do know that Learning to Fish and GitHub are going to play a big role in all of our futures. Watch this space!