Legacy in IT and what to do about it

Introduction

Today's business demand high speed, and usually legacy IT is blamed for slowing business or high cost from existing players. This view provides comfort, as we are blaming someone in the past for something that is happening now, and usually with resignation.

IT legacy:

1. is not bad by itself, it is actually a significant asset for many companies
2. not everything that is new is supporting speed and low cost
3. it is not contained only in IT function.

Avoiding the negative impact of outdated IT legacy is a continuous task that involves technical, procedural and cultural aspects of IT.

What is legacy

If we start with the definition (Merriam/Webster):

• a gift by will especially of money or other personal property.
• something transmitted by or received from an ancestor or predecessor or from the past.

Initially, legacy is not bad ( by the way, I accept donations of legacies in cash from those that says that every legacy is bad). When used as an adjective (Dictionary.com): "of or relating to old or outdated computer hardware, software, or data that, while still functional, does not work well with up-to-date systems." the negative aspect of IT legacy surfaces.

Legacy IT is not good or bad by itself. Like many other assets, it depends on maintenance and the proper evolution of the systems. Let us highlight some positive aspects of good IT legacy:

• It contains very valuable assets that take time and money to develop. While it is true that starting today it will probably take less money and time, they have been serving the business functions for years, and they have already (usually) been paid.
• They have been tested in different environments and, with proper maintenance, bug and errors have been detected and fixed.
• They keep and execute business knowledge that has been gathered and validated through thousands of interactions.

But IT systems that have not properly evolved during years become a serious business problem due to:

• Longer time to market as it takes time to update them.
• The stability is usually achieved by reducing changes, and deployments are rare, painful and prone to issues.
• Cost is high
• Difficult to recruit new employees with specific knowledge in old technologies.

Components of legacy

Legacy in IT is usually envisioned as a monolithic, COBOL system running on a mainframe, buried in old datacenters. This is a simplification that usually comes from vendors of technology that aim at replacing this technology stack.

IT legacy has different components technical, procedural and even cultural:

• Instead of monolithic systems, the problem is the high dependency between different areas of code and files that makes very hard to change one piece of software. This high dependency can be easily achieved in distributed systems as well without proper governance.
• Data structures that maintain business-relevant information. Any change in one of them demands significant changes in many areas of code, and sometimes even redefinition of data storage. De-centralized data structures demand an inventory of systems with the same data and endless discussions about basic business questions. If you have ten different structures storing information about customers, you will probably have (at least) ten different answers to how many customers do we have.
• Interfaces between different systems, be it internal or external to the company. As the number of different interfaces, technologies and approaches grow over time, to update all the interfaces can become a difficult task.
• If knowledge about the system is not properly kept updated inside the company, after some time it is really difficult to apply changes as thorough revisions of code are demanded to double check side effects of local changes.
• Procurement, contract templates, vendor management, audit processes, sourcing policies that make any change of the process, vendor or technology really difficult to achieve. Many of these policies were developed for a different scenario and IT teams struggle to achieve agility and speed due to constraints in these areas. In many occasions IT agility goes against these procedures.
• The culture of blame & shame. When there is a problem in IT systems and business areas hammer and blame IT function, they are planting the seeds of processes that will bring business functions into IT processes to ensure that they can also be part of the issue. This is one of the reasons why many business functions have to develop detailed requirements, so as to avoid that they can later blame IT.
• This culture of blame & shame can be extended not only to specific IT issues but to revenues and sales target. Too many business areas push the ownership of their business outcomes to IT through an endless list of IT requirements just to be sure that it cannot be delivered, and have an excuse to explain the challenges in reveniew.
• Too many times IT functions have developed a defensive culture so, instead of working to support business functions and take ownership, they are also pushing IT accountability into business areas.

Is everything new legacy-safe?

What brings the wrong side of legacy is not the technology itself, but developing wrong practices, culture and procedures that will hinder the future evolution of systems to keep pace with higher demanding business.

Whatever new language, platform, methodology, structure can become legacy very easily, even from the start. Many of them provide short-term amazing benefits that are against evolution in the long term.

An action plan

IT has to support business today and in the future, taking whole ownership of the evolution of the systems. IT bad legacy is like gaining weight. Easy done on through small decisions that seem good in the short term but accumulate in the long term.

To tackle the wrong effects of legacy, there are some actions that must be taken constantly:

• IT legacy is not an IT issue, but a business problem. When short-term benefits are against long-term evolution, there is a business call to balance them.
• Establish a culture of evolution with business areas, with a balance between lack of issues and proper tackling of those.
• Define a proper project portfolio that includes specific actions to evolve and even sunset legacy systems in a controlled way.
• Control the complexity in the IT landscape, as adding a new system today can seem a good idea, while in the long term can become a source of complexity.
• Define and evolve the business architecture to ensure that speed and adaptability are maintained and complexity and dependencies between systems don't grow out of control.
• Analyze periodically the degradation of speed and agility in delivering functionality to business.
• Do not block initiatives from business areas that can give them flexibility in the business processes while maintaining the core of the business stable and consistent. One interesting area is the use of low coding platforms with robust and well-documented API.

What are your views about legacy in IT?