An Alternative Strategy for Legacy Modernization

4 Pages

Organizations today face a variety of challenges that lead them to consider modernizing their legacy mainframe applications, and sooner rather than later. Such applications have typically been maintained over many years. Legacy code contains a myriad of poorly documented and difficult to understand patches. Older programming languages use simplistic ways to segment functionality, which means changing one part of an application can break others. These factors add up to continual spending on legacy maintenance and difficulty keeping pace with changing business needs, industry standards, and regulatory requirements.

Other legacy challenges include limited Internet access and data sharing, obsolete technology, and spiraling costs of legacy platforms. Hardware and software vendors announce end of support for older products, legacy programmers retire, and educational institutions no longer teach those older skills. Global awareness of the need for legacy modernization is rapidly growing

Unfortunately, the modernization approaches one might typically consider come with a high price tag and significant technical risk. It’s little wonder that the most common decision is to stick with the existing applications for a while. After all, the required functionality is in place and serving enterprise needs.

Maintaining the status quo can work for only so long, however, before the factors described previously force companies into action. Then the question becomes, what’s the best strategy for moving forward? This article compares the alternatives, including a lesser-known option that offers several advantages.

The High Cost of Redevelopment

A typical first instinct is to consider replacing a system the same way it was originally built, with traditional manual development. This is a tempting option for many organizations, since they already have an IT organization in place to execute development projects and that’s how they’re used to acquiring business-specific functionality. Familiar approaches tend to be attractive and a redevelopment project has an existing system to serve as a working requirements specification. So, this type of project should be easier than the original development, right? Unfortunately, history doesn’t support that argument.

A redevelopment project must recreate functionality that has evolved over many years, growing far beyond the scope of the original application. Sifting manually through millions of lines of source code, multiple layers of patches, and poorly documented changes is a complex, lengthy, error-prone task. Our industry is rife with stories of redevelopment projects that ultimately failed, years late and hugely over-budget. A common pattern is to propose an aggressive schedule to gain approval via the corporate budgetary process. The project is typically far from complete when the next fiscal cycle comes around, so the project must seek additional funding. The common response is, “Why should we give you more money when you haven’t delivered what you said you would?” Even efforts that succeed in producing a replacement system cost much more than they should.

Package Replacement

Purchasing replacement Custom Off-The-Shelf (COTS) applications can be a highly effective approach when packages are available that provide the required functionality. The results of the acquisition are predictable in the sense that costs are known and the package can be tested upfront.

Packages are rarely a perfect fit with business needs, however, which often means an extensive customization effort. As with custom development, such projects tend to be time-consuming and expensive. Moreover, a large percentage of corporate applications support enterprise-specific functions and business rules. Often, no COTS packages are available to support such unique functionality.

4 Pages