At what point does a new vehicle become used? When it rolls off the lot? After an acceptable number of kilometers? When the new car smell has faded away? The same question can be asked with IT systems. At what point does a system become a legacy system? When it is released into production? After an acceptable number of years in production? When the user experience no longer feels modern?
A legacy system is an old method, technology, computer system, or application program that is still in use. There is the idiom “Do not fix what is not broken,” but with IT systems it’s not entirely clear when a system has reached a broken state. However, these systems may underpin the entire organization and therefore it is unwise to wait for a failure as the trigger to act.
There are common action triggers, and technical debt usually plays a significant role. Like a new car, the IT system requires regular maintenance in order to function effectively. Technical debt can accumulate and if not regularly paid down, the accrued interest can become so large that the effort to maintain is greater than performing a full refresh. Much like a used car, at some point, the IT system is sent to the proverbial scrap yard. Another trigger is an existential crisis - or in today’s buzzwords, “disruption”. Consider small professional service firms being disrupted by freelancing job boards. These firms must now compete both for talent and revenue. The modern and easy to use platforms are forcing firms to refresh their processes and technology platforms in order to stay technology relevant. A third trigger is based on platforms falling out of service. Many solutions are built on platforms developed by large service providers like Microsoft, Oracle, or IBM. These platforms are developed, maintained, and eventually replaced. When these products reach end of life, they stop receiving updates for functionality and security leaving users vulnerable if they do not switch platforms. Lastly, some systems are replaced as part of a managed refresh set out by leaders under the guidance of a strategic planning process.
Regardless of the trigger, we need to consider what is important when replacing a legacy system. Modernizing while maintaining the exact same functionality is a waste of resources. Take for example a paper application process. The tool employed is a physical item that allows a user to record information so that an agent can interpret, make a decision, and take an action. On a whole the system is not very intelligent and if the paper form is replaced directly with an electronic form, the system has not gained any intelligence. By digitizing a paper application process, the IT system can have intelligence introduced improving the experience for both the user and agent. Are all fields required? What information in one field can be used to fill out other fields eliminating steps and improving the user’s experience. Can the entire application be replaced with the users sign in credentials? While paper processes are now the minority, with each system refresh the tools of the day are exponentially more intelligent than the predecessor. When refreshing your system, there is the opportunity to revisit existing processes and reimagine them with more intelligent solutions. We see this today with firms racing to incorporate machine learning and automation tools into all areas of their businesses.
Now you know that you want to incorporate more intelligence in your processes - what next? In many cases technology makes it easy to expand the scope of influence and reach. It is important to understand that when building a system, it is the exceptions that will kill you, so kill the exceptions. In robust system design, it is the exceptions that cause cost overruns; and accumulate the initial rounds of technical debt the organization must manage. Eliminating the need to process an exception will provide tremendous savings.
Like new cars, new IT systems are expensive. The value that can be derived is a function of the design, how it is used, and how well it is maintained over the product’s lifetime.