Three words that can turn a CIO’s heart to stone are modernization of the legacy system.
Too often the concept refers to a labor-intensive and energy-absorbing effort to redesign applications that were architected in the early 2000s – if not earlier – into something akin to 21st century performance and user experience (UX). The result is almost always unsatisfactory. In addition to the time, money and effort spent, there is also the opportunity costs not to engage in other more transformative projects. And the end result is rarely as nimble, flexible, functional or user-friendly as a more recently designed system.
But it doesn’t have to be that way. Taking a structured approach to modernizing legacy systems can minimize the effort and cost of upgrades while ensuring that the results are optimal in terms of functionality, performance and user experience.
A structured approach to modernizing legacy systems
Taking a structured approach to modernizing legacy systems means asking two key questions and then taking the right approach based on the answers to those questions. It also means making the modernization of existing systems a continuous process, rather than a one-off project.
The hardest part for many CIOs is forcing themselves and their teams to methodically answer questions they are sure they already know the answers to. But the effort is worth the effort: Many times the answers will allow tech pros to avoid labor-intensive efforts altogether.
1. What is your organization’s definition of heritage?
Your answer to this question will determine which systems to focus your efforts on and which to leave out for now.
According to Mobindustry, a Ukraine-based software company, âA legacy system is any system that hinders further development, does not allow easy integration of new features, and slows down the day-to-day operations of a business. In short, an old system is difficult to maintain, support, and expand. “
The key point here is that heritage does not want to say old. Apps completed last week may fall into this category if the developers have not followed. up-to-date architectural principles, either by ignorance or by haste. The hasty development of applications is a frequent source of technical debt.
Therefore, the first step is to sort all system modernizations into three categories: legacy, intermediate, and modern.
Existing systems are those that require modernization, regardless of their age; modern systems are the ones that don’t. Intermediate systems and applications allow modernization but may not be the top priority.
A CIO will often resist this critical first step on the grounds that business stakeholders have reached the boiling point of tolerating a particular application and demand that it be immediately modernized. The thinking usually goes like this: “We already know which systems need to be modernized, we don’t need to waste time classifying them.”
It’s tempting to think so, but it shouldn’t be. Even though the legacy systems modernization team only has the bandwidth to work on a single application, it is important to know which other systems are on the list so that best practices apply to all.
In other words, don’t treat legacy system modernization as one ad hoc project for a critical application. Think of it as an ongoing process following a consistent methodology, applied to the applications that need to be modernized the most.
Each system must have a classification from the time it goes into production. Review your system classification at least annually, as systems that were previously classified as intermediate or modern will inevitably be inherited as technology and development practices advance.
2. What is the best approach for modernizing legacy systems?
By now it should be obvious that this question concerns the best approach for a given application, since the aim of a structured methodology is to apply the optimal approach on a system-by-system basis.
To answer this question, we need to review the main approaches to modernizing legacy systems.
Gartner refers to the five Rs: re-host, refactor, restructure, rebuild, replace. That’s one way of looking at it, but it’s both specific – re-architecture and reconstruction tend to overlap – and rather broad within the specific goals of modernizing the legacy system.
A better way to think specifically about modernizing legacy systems is to think in terms of these five approaches: encapsulate, re-platform, refactor, redesign, rethink.
Encapsulation a system – via Apis – Essentially limits access to the system to match the information and workflow of modern systems connecting to it. You can, for example, integrate the system into a common UX platform through an API so that its information is displayed in a format that is easily usable by users to provide optimal UX.
The value of encapsulation is that it solves the short-term pain of a bad user experience and makes a legacy system look like a modern system. The downside is that it doesn’t solve the fundamental problem of a legacy system – maintenance overhead. An encapsulated legacy system is always a legacy system; it will continue to consume as much labor and cost once encapsulated as before. Since many studies suggest CIOs spend up to 80% of their budgets supporting and maintaining existing systems is not a trivial consideration.
Replatform does it sound like: moving the system – and, possibly, all of its data and storage resources – to another platform. Typically, this is either a colocation facility or IaaS. Replatforming is a great option when it comes to meeting short-term goals, such as shutting down an on-premises data center or avoiding a costly WAN upgrade to allow remote users to access the system.
However, the change of platform is an intermediate step. Moving an issue to IaaS or a colocation facility can fix short-term issues, but the costs of maintaining cloud services can add up, and paying cloud costs for legacy applications is just another form of debt. technical.
Refactoring, as defined by Alliance Agile, consists of “improving the internal structure of the source code of an existing program while preserving its external behavior.“Specifically, this includes improving the objective attributes of code – length, duplication, coupling, cohesion, and cyclomatic complexity – which correlate with ease of maintenance, improved code understanding, and increased longevity. Use of reusable design elements and code modules The Agile Alliance continues to emphasize that refactoring does not mean rewriting code, fixing bugs, or improving observable aspects of the software such as its interface.
One way to understand refactoring is to think of it as code optimization. That is, the developer does not change the functionality or the basic coding algorithms, but rather examines the code to ensure that it is fully understandable and instantiates good agile development hygiene. You can also think of refactoring as removing technical debt from code – replacing all coding shortcuts and suboptimal implementation with a cleaner, optimized design.
Refactoring is a good way to reduce the costs of supporting a system, and many organizations are deploying it as part of their cloud migration strategies. The dilemma with refactoring, from a legacy system modernization perspective, is that it fails to meet the challenge of systems that are built on outdated and outdated architectures.
Overhaul encompasses both re-architecture and reconstruction, including rewriting code. It is essentially a modernization of architecture and design. This is the option that most enterprise technologists immediately turn to when considering modernizing a legacy system, because it is the most intuitive: providing the same business functionality but using techniques and techniques. modern coding architectures.
The overhaul is certainly a viable approach, and it’s the one that goes the extra mile to provide a seamless clean up of nut soup. UX and support costs are expected to improve following a system overhaul. But, there is another level that CIOs should not rule out.
Rethink is an underused approach of rethinking the entire business process that a system is designed for. Most corporate technologists think of business requirements as set in stone, but they are not. Sometimes it’s the business requirement itself that’s obsolete.
A simple example: During the COVID-19 pandemic, many companies struggled to enable a signature-based workflow for various documents with employees working from home and unable – for compliance or security reasons – print documents.
The real solution was not to modernize applications but rather to rethink the requirement for a signature-based workflow in the first place. With efficient authentication, checking a box can be as intransigent as leaving a signature.
Many business requirements are outdated or reflect the limitations of technology at the time. For example, most CRM systems predate LinkedIn and were not designed to maintain contact with individuals during job changes.
Often the best approach to modernizing an existing system is to rethink the business process that the system serves. Often times, you will find that the process itself is outdated.
The answer to the question “Which approach is the best?” Â»Depends on a range of factors, including cost, timing (i.e. how quickly modernization is to occur), number and type of other existing systems that need to be modernized, the company’s cloud strategy and overall business strategy.
The important thing is to consider all existing systems against all possible modernization alternatives, and then select the most logical approach for each system. A key factor to consider is the extent to which rethinking is part of the overall modernization strategy; sometimes rethinking can wipe out entire categories of systems.
Finally, develop a roadmap to modernize all systems, not just those that are currently classified as legacy. The roadmap should include a regular review of all systems to determine when they are slipping into the legacy category.