Black-Box vs. White-Box Legacy System Modernization Methods

By Rachel Nitschke | Nov 16, 2017

240 billion.

This is how many lines of code are tied up in legacy systems. Maintaining this code, which is fragile after years of “fix-it-quick” patches, takes too long for many companies’ IT teams to update. As the threat of digital disruptors looms over many industries, companies will fall behind if critical IT resources continue to be diverted away from strategic innovation investments. The business logic trapped in legacy systems provides competitive advantage, and one that many companies do not want to risk losing.

CIOs know that changes need to happen with their legacy system, but deciding between maintenance, replacement and modernization is difficult. Continuing to maintain the system is the riskiest long-term and safest short-term option. The costs of this will only increase as the system gets older, and those extra years make the inevitable replacement or modernization more difficult.

Replacing the system is a huge cost and resource investment. If the system is critical to your company’s functioning, then downtime for the changeover and implementation will be impossible. IT leaders will then have to make sure both systems can work side-by-side, adding even more resource costs and time delays to the replacement project. The new system also requires extensive testing, or the company risks a situation like Hershey’s in 1999 when a botched ERP rollout caused $100 million of customer orders to go unfulfilled during their peak Halloween season. The company shortened the timeline against analyst recommendations and cut corners on user testing. Any changes to legacy systems are too important to cut corners. IT teams also have their own track record to consider: 25 percent of software development projects fail outright and 60 percent produce substandard or ineffective products.

After working with numerous large enterprises and developing our own projections, it’s apparent that the advances in middleware, service-oriented architecture and APIs, have made modernization the most cost-effective strategy. A redesigned interface, mobilization of key functions, or virtualization of data will meet both business’ and users’ needs—without the short-term costs of replacement and long-term vulnerabilities of maintenance.

Legacy system modernization– when done correctly– will preserve the valuable business logic of the system and still upgrade the system to better meet functional needs. Modernizing legacy systems significantly reduces long-term costs by optimizing business processes (and even automating certain manual tasks) to save labor costs, and improving the overall agility of the application to meet today’s business needs.

As the IT team is able to spend fewer resources on legacy applications, it becomes more and more possible to focus on more strategic innovation investments that will be so crucial to the future of the company. Gartner estimates that one out of every four companies will lose competitive ranking due to a lack of digital business competence by 2017. CIOs can improve their chances of being in the other three out of four companies who are able to maintain or even grow their market share by investing in a legacy modernization effort.

White-Box Vs. Black-Box Modernization

Modernization efforts typically fall into two categories: white-box and black-box.

  • White-box modernization involves reverse-engineering the internal operations of the system and developing an abstract model of the system in order to restructure it into a more modern architecture.
  • Black-box modernization is only concerned with the inputs and outputs. Generally, companies pursuing this effort will have an end goal of developing another layer of software to conceal the old system through a modern interface.

White-box modernization, because of the difficult abstraction and reverse engineering approach, requires a significant amount of time and effort. Black-box efforts are not without their own resource costs, but pale in comparison to the white-box route, which is the only option for dealing with the issues in the underlying code. For white-box modernization, IT leaders commonly choose to follow a technique called “program understanding” to develop the model that provides a full understanding and analysis of the old code. After this code is painstakingly analyzed, the stakes become even higher: the team has to now perform some code restructuring. According to researchers at the Software Engineering Institute, the most popular technique for code restructuring is program or code splicing.

If the code does not have major issues, many companies choose to use the less resource-intensive black-box modernization. Improving the user experience with a black-box effort can generate significant financial gains on its own. As the workforce demands more mobile technology, especially for 24/7 operations, delivering key data points of business intelligence or making it easier to log data from a mobile device saves employees’ time and frees them up to pursue more analytical or creative tasks.

Managing Risk with the Legacy System Modernization Process

With any large IT project, it’s important to perform a risk assessment and do as much as possible to mitigate risk. There are a number of IT risk management and assessment methodologies:

    • COBIT 5— ISACA, previously known as the Information Systems Audit and Control Association but now just goes by the acronym, released the latest version of their COBIT framework in 2012. According to an interview with Ben Tomhave and Erik Heidt from Gartner, the framework is very prescriptive with a highly detailed set of processes, but one that is also meant to be customized to the situation.
    • ISF IRAM2— Tomhave describes this framework as “cookie-cutterish,” because it is prescriptive, like COBIT 5, but does not require the level of customization. Both COBIT 5 and ISF IRAM2 tie IT risk to business risk, which is helpful given the nature of today’s IT environment.
    • OCTAVE Allegro— Carnegie Mellon University developed this framework, initially called OCTAVE, in 2001 for the United States Department of Defense to deal with cyber assaults. Tomhave contrasts this framework with the previous two as a much broader, more general framework, although critics note that it does not produce a detailed quantitative analysis.

What is your biggest challenge with legacy modernization?


optimize_legacy_systems
 

Get in touch

Marketo Form