hernaes.com

Innovation – Finance – Technology

Uncategorized

Why is legacy tech a problem and how do we fix it?

Servers_at_LAAS_28FDLS_200729_0389

One of the issues for incumbents when facing a new digital reality is the burden of legacy technology. Why exactly is this a problem, how do we end up with legacy IT, and how should we approach it?

Legacy IT and technical debt have been a topic for IT departments for a long time, but as the world becomes increasingly digital, legacy becomes such a bottleneck that the risk of relying on outdated technology must move from the IT department to the top management and the boardroom. Launching an app does not make you digital, and moving ahead in the front-end without simultaneously addressing the tech you already have stored up in the engine room creates numerous pitfalls.

From a business perspective, cleaning up the engine room almost never generate a positive business case as it will neither produce any additional income nor result in cost reductions that are comparable to the cost of modernizing. As a result modernizing legacy is often postponed indefinitely. In order to make this a priority, one must look beyond the present and analyze the potential missed future opportunities of relying on yesterday’s technology as well as the operational risk related to running on outdated software.

Legacy IT is often translated to old IT, and while some of the issues regarding legacy IT is purely related to a system that has passed its expiration debt, most legacy issues or technical debt does not occur solely because of old age. As the world moves ever faster, any IT system starts decaying from the instance it is set into production. A seemingly new system rushed to meet last quarter’s sales target may expose the organization for the same amount of technical debt as an old system that has been faithfully doing its job for decades. Hasty development may lead to a lack of testing, poor code quality, and insufficient documentation.

This will eventually lead to tying valuable resources up in bug fixing and system maintenance instead of spending time developing new solutions. As resources get tied up in maintaining old or complex code, those resources, and the systems they maintain become inseparable, resulting in an operational risk where organizations are depending on system-critical personnel and or domain-specific competence that is hard to come by.

This applies to both old and new legacy, and a Forrester Research survey of more than 3,700 companies estimated they spent an average 72 percent of their IT budgets on keeping existing systems running.

The need for speed might be the culprit for legacy created in the near past. However, the inability to move fast is one key limitation when facing legacy IT. Legacy systems are in many cases designed to support industrial processes, and at best have been adapted to the information era. The common denominator for these systems is that they are built for heavy lifting rather than speed and agility.

Speed or lack thereof will also be present in various shapes. As most digital applications rely on data, legacy IT may pose significant limitations on user experience as data is often updated through overnight batches rather than real time. When you can have same-day delivery of physical merchandise through e-commerce, customer expectations are set, and no one will wait overnight for a data update. As an example, a survey of 2,000 UK adults, 43% expect to be able to open an account instantly – however, only 37% of traditional banks and 40% of challenger banks can offer this service.

When facing a new digital reality when it is the fast eating the slow rather than the big eating the small, this poses serious limitations on future business development. According to Bain, IT has become digital’s Achilles heel when it comes to getting organizations up to speed with a digital world. The complexity associated with legacy IT is a serious obstacle for time to market in many organizations.

Legacy IT can also result in serious cybersecurity vulnerabilities. The most famous case being the Wannacry ransomware attack in 2017. The virus exploited a vulnerability in the Windows operating system, shutting down critical infrastructure for days as it affected an estimate of 45,000 organizations.

One of the organizations that were hit the hardest was the NHS in the UK. 600 surgeries were affected and 19000 patient appointments were cancelled. The root cause was the continued use of Windows XP for years after commercial support for the operating system had ended, as upgrading the system was considered too costly. In the aftermath, the department of health calculated that the WannaCry attack cost the NHS £92m.

One attempted solution to antiquated technology and siloed systems in the past was to integrate systems across silos as well as tweaking existing systems to behave in a desired manner, straying away from the initial purpose of the system. With this approach, the risk of making things worse and increasing complexity is guaranteed. Both forcibly marrying legacy systems that are not initially designed to collaborate as well as tweaking and tuning systems to solve problems they are not intended to solve are surefire ways to multiply legacy problems in the future. Painting stripes on a horse and calling it a zebra is not a good approach to overcoming legacy tech.

Others have tried to solve this by deploying a bimodal, or two-speed IT model. According to Gartners CIO survey in 2017, 71 percent of top performers report that bimodal IT improved innovation.

While it is a temptingly simple way to solve the issue, it has one real flaw: It doesn’t work. Research shows that over time, businesses that put digital on a fast track without addressing the legacy IT are bound to hit a wall. They find their digital efforts take more time, cost more money and deliver less value than they anticipated.

According to Bain & Company, a bimodal approach typically raises costs, complexity and expectations without delivering results. Choke points and frustrations arise when fast-moving initiatives are bogged down, waiting for the slower legacy system. External departments don’t understand which team to use, and when, and why some parts of IT don’t respond as quickly as others—and employees left behind on the slow track may grow downright resentful.

This is also supported by Forrester, who emphasize the risk of creating opposing cultures within IT, where it may end up with pitting the cool kids doing all the front-end stuff against developers stuck with back-end housekeeping. This will eventually put any company attempting to pursue two-speed IT at a disadvantage when looking for digital talent, a dual culture of fast and slow will create the sense of an A-team moving fast and a B-team moving slow. This causes a problem because having top talent in the slower group is particularly important. This is where the hard challenges of transforming legacy systems are tackled as well as the larger part of IT spending.

Whether you tweak and tune, freeze the core and build around it or attempt a bimodal operating model, what all these approaches have in common are that they are attempted workarounds. The only way to handle legacy IT and clean up the spaghetti is to tackle the issue head-on.

Have a plan. The best approach depends on the problem you’re trying to solve. Replacing legacy IT is hard, and there must be a clear purpose to do so. Be aware of the limitations posed by current systems and architecture and which business outcomes you wish to achieve by migrating from legacy IT to a modern platform.

Make sure to identify the root cause of the challenges you wish to solve. Plastering the symptoms will only make things worse in the longer run.

Don’t go overboard with jumping on the hype bandwagon of new technology when modernizing IT. Cloud and/or Software as a service is no silver bullet, blockchain is no magical trust generator and AI is only as smart as the data you feed it and the talent designing the algorithms. Choose technology and solutions based on what is fit for purpose rather than what is considered cutting edge.

Be prepared to encounter unexpected interdependencies. At the first test migration on is almost guaranteed to be in for some surprises in terms of unexpected occurrences. Make sure your pan have enough margin for uncertainty to tackle these instances.

Make sure you have the right competence to make sense of your legacy tech. Behind thousands of lines of antiquated code (often written I archaic languages such as COBOL and Fortran) lies essential business logic and workflows that your organization might want to keep.

Involve the end-users. No matter how shitty an old system is, there’s usually someone who has grown accustomed to it, and prefer to continue the struggle than to learn something new.

From top-down principles to actual implementation, there is no one-size fits all approach. For reference, Gartner propose seven modernization alternatives:

  1. Encapsulate. To leverage and extend an application’s features and value, encapsulate data and functions in the application and make them available as services via an application programming interface (API). Implementation specifics and knowledge are hidden behind the interface.
  2. Rehost. Redeploy an application component to another physical, virtual or cloud infrastructure without recompiling, altering the application code, or modifying features and functions.
  3. Replatform. Migrate an application component to a new runtime platform. Make minimal changes to code to adapt to the new platform, but don’t change the code structure or the features and functions it provides.
  4. Refactor. Restructure and optimize existing code without changing its external behavior to remove technical debt and to improve the component’s features and structure.
  5. Rearchitect. Materially alter the application code so you can shift it to a new application architecture and fully exploit new and better capabilities of the application platform.
  6. Rebuild. Rebuild or rewrite the application component from scratch while preserving its scope and specifications.
  7. Replace. Eliminate the former application component altogether and replace it, taking new requirements and needs into account

 

These may give some guidance, but embarking on a legacy migration journey need to be tailored to the organization. You need to take into account both your starting point and expected outcome.

At the end of the day, bear in mind that the cutting edge system of today is the legacy of tomorrow. Make sure to make a habit of investing in continuous platform renewal. In the long run, this will be more cost-effective than waiting to do a lift and shift of obsolete tech

4 thoughts on “Why is legacy tech a problem and how do we fix it?

  • Pingback: Når utdaterte it-systemer blir en hodepine – hernaes.com

  • Joao Valentim Bohner

    Christoffer,

    Congratulations for the excellent article!

    You well summed up the path not to follow: “Painting stripes on a horse and calling it a zebra is not a good approach to overcoming legacy tech.”
    IMO, and, to my knowledge, technology today has the ability to ‘eliminate’ legacy systems.
    This allows customers to be served quickly and on a 24/7 basis.
    And at the end of the day you don’t have to do batch processes.

    Obviously the way forward begins by reshaping the conduction of business – not only financial – but ‘business’.
    Business processes have to be conducted ‘corporately’ rather than ‘per line of business’.

    Reforms are anticipated in the organization itself, in employee roles, in simplified processes and in corporate governance.
    The major reform, however, will be observed in the technological treatment of information through reusable functions (microservices) as well as in the way of storing data – Single Source of Knowledge.

    Better times technology will give us.

    Reply
  • Pingback: It has been an amazing journey, but now it is time to leave Sbanken – hernaes.com

  • Pingback: Hvorfor er teknisk gjeld et problem og hvordan løse det? – hernaes.com

Leave a Reply

Your email address will not be published. Required fields are marked *