No word strikes more fear and loathing into the hearts of CIOs than legacy. The term is so reviled that software marketers are loathe to mention it whatsoever, instead succumbing to euphemisms like mature or elderly or the perennial favorite, systems of record.
Legacy technology, of course, has always been the ball at the end of every enterprise CIO’s chain since companies first defined the CIO role. And as a result, legacy modernization has similarly been an oft bandied-about priority – one that too often falls to the budgetary axe.
In spite of a good half century of such legacy struggles, however, today the situation has fundamentally changed. Digital transformation priorities coupled with new technologies and IT best practices are empowering organizations to make better headway with their modernization efforts than ever before.
And those enterprises who divert their attention and resources elsewhere, choosing instead to leave their legacy alone? Many will find that such a strategic error will make them less competitive, and some will even find themselves in the impossible situation where it’s simply too late for the organization to recover.
Any information technology – hardware, operating systems, middleware, applications, etc. – may end up as legacy. Nevertheless, people often paint legacy with too broad a brush.
Mainframes, for example, are frequently modern systems with modern applications. Not always, however. Some mainframe apps, as well as midrange systems, older versions of Windows and Unix, and many other platforms, systems, and applications are truly obsolete.
In fact, legacy doesn’t even necessarily mean old. Legacy refers more to the amount of technical debt a particular piece of technology has – in other words, how expensive and difficult it would be to resolve any of the issues the subject technology suffers from that keep it from meeting current needs.
The legacy modernization challenge has thus always boiled down to an economic argument: how expensive the pain an out-of-date system is costing the organization, vs. the all-in cost of modernizing that legacy – including all the indirect costs of making the transition from old to new, including downtime, retraining, customer resistance to change, etc.
The rise of hybrid IT has thrown a monkey wrench into these traditional economic arguments.
Hybrid IT is a workload-centric management approach that seeks to abstract the choice of deployment environment across multiple public clouds, private clouds, and on premises and cloud-based virtualized environments, as well as traditional on-premises systems, including legacy assets.
Hybrid IT represents the overarching paradigm for modern IT operations. However, in spite of the inclusion of legacy under hybrid IT’s umbrella, we don’t mean for hybrid IT to perpetuate legacy. Rather, hybrid IT gives enterprises the means for modernizing legacy.
Within this broader strategic context for hybrid IT, then, there are three essential enablers of this new context for legacy modernization.
First, we have the rise of containers and microservices, within a comprehensive architectural context we might call microservices architecture.
As enterprises move forward with deployment of containers at scale, the best practice approach to microservices architecture rethinks enterprise applications as clusters of microservices, where architects organize such clusters by business domain in order to meet changing business needs at scale.
When the challenge at hand is the modernization of a legacy application, microservices architecture provides a modular approach that both lowers the risk of the transition while empowering modernization teams to work in parallel with each other as well as other development teams.
In fact, modernizing a monolithic legacy app is no longer a monolithic task in its own right. However, such modernization requires the creation of new application capabilities, which brings us to the second essential enabler: enterprise low-code platforms.
One of the reasons why IT managers in the past have recoiled from modernization tasks is because of the cost, time, and risk inherent in hand-coding replacement functionality. Low-code changes this equation, lowering both the time and risk of application creation.
However, not all low-code vendors focus on legacy modernization, as bespoke (custom) app development is often the sweet spot for such platforms.
In response, a subset of the low-code space, what we like to call enterprise low-code, empowers software teams to modernize legacy apps as well as build new ones, where the focus on microservices is the key to both goals.
Modern architecture and modern development tooling are two legs of the legacy modernization stool – but without the right organizational and cultural context for such modernization, the stool will fall over.
The third modernization enabler, or leg of our stool, as it were, is DevOps. DevOps is an automation-driven model for collaboration across the IT organization, including development, quality assurance, operations, and security – as well as an increasing level of collaboration with people in customer-facing roles that represent the ‘business.’
As with low-code platforms, however, DevOps is no longer just for bespoke development. DevOps is also an essential enabler of legacy modernization, as the teams responsible for maintaining legacy apps must be an integral part of the collaborative context of DevOps.
In the past, modernization has often succumbed to the ‘throw it over the wall’ mentality that DevOps seeks to resolve. For example, many CIOs may have decided their mainframes have got to go, thus putting the entire IT organization into turmoil.
Instead, DevOps calls for pushing such decision making down to cross-functional, collaborative teams – who might determine, for example, that the best way to deal with a legacy mainframe app is to modernize it in place.
In other words, the right modernization decision may very well be to update an existing mainframe application on the mainframe, perhaps rewriting it as microservices, perhaps even using an enterprise low-code platform with mainframe support.
However, without DevOps – with its automation and cross-functional collaboration, as well as pushing decision making down to the cross-functional teams – neither microservices architecture nor enterprise low-code will deliver the full transformative value of legacy modernization for today’s hybrid IT infrastructures.
The combination of microservices architectures, enterprise low-code, and DevOps lower the cost and risk of legacy modernization. Just in the nick of time, as modern digital priorities are increasing the importance of such modernization, thus placing a greater negative value on the pain that legacy assets are causing the organization.
Gone are the days where enterprises can put up with such painful legacy. Modern IT requires an appropriate modernization strategy that takes into account this economic argument, while also better understanding the appropriate choices for any particular legacy asset.
In fact, one of the most important lessons of this Cortex newsletter is a greater understanding of the complexities of legacy assets, and thus the concomitant complexities of their modernization.
Legacy assets come in many varieties. Sometimes it makes sense to replace them entirely. In other cases, its possible to modernize them in place. And yes, there will always be situations where it is best to leave a legacy asset untouched. After all, if it ain’t broke, don’t fix it.
Given the vast complexity and rich possibility of today’s modern digital age, however, the likelihood that leaving a legacy asset alone is the best choice is dropping quickly – and the modern hybrid IT context for enterprise technology reflects this rapidly changing reality for enterprise legacy.
Copyright © Intellyx LLC. Intellyx publishes the Agile Digital Transformation Roadmap poster, advises companies on their digital transformation initiatives, and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credit: Carl Berger Sr.