Moving From Your Legacy System – COBOL Conversion, Cost and Consequences

Introduction

In 1960 COBOL, one of the first programming languages, was developed and now fifty-five years later, more than an estimated 200 billion lines of COBOL code are still in functional existence. COBOL, or Common Business-Oriented Language, is primarily used for business, administrative, and large-scale systems and its applications are seen universally, such as in banking, health care, and government agencies like the Social Security Administration and the IRS. However, since its beginning in 1960, hundreds of other programming languages have been created, most notably Java, C++, and Python. As young developers find newer, dynamic coding languages more lucrative, COBOL-run systems are headed towards what could easily be the biggest skills gap the software industry has ever faced. As a result, organizations continue to lose employees that develop and maintain their COBOL systems. Maintaining a legacy COBOL system is a feasible solution, however organizations need to reevaluate their IT strategy to ensure their approach going into the future is proactive and feasible.

The Rise and Fall of COBOL

Upon COBOL’s development, computer usage was effectively quantified into three categories, all powered with their own respective coding languages: supercomputing, artificial intelligence development, and business operations. COBOL, used for business operations, was specifically designed for the un-savvy programmer- each action performed in COBOL must be explicitly laid out, making COBOL a more approachable yet verbose language as compared to its 1960’s language counterparts. Industries such as banking and health care inundated their fields with computer automation, using COBOL to write their growing programs. Even in the present day, COBOL performs backend transaction processing and batch processing capabilities very well. Its computing time is much faster than compared to modern languages and runs with very low error ratings.

Although the latest version of COBOL was released in 2014, in the past twenty years COBOL has become widely known as an outdated legacy language. The majority of US universities have stopped offering COBOL courses in their computer programming curricula because young developers are more focused on contemporary languages like Java and C++ which comprise the majority of jobs in the computer programming market, as shown in the figure above. This lack of education and interest coupled with an ever-increasing age of current COBOL developers (the average age of a COBOL programmer is between 45-55 years old¹) has led to an enormous demographics gap between skills offered versus employer needs, thus creating a favorable labor market for current COBOL developers. As years progress, the number of COBOL programmers continues to decrease while the cost to maintain COBOL systems continues to rise, driving development and maintenance labor costs for organizations (with often decreasing IT budgets) higher and higher.

Stuck between a Rock and a Hard Place

Many argue that COBOL is here for the long run because organizations that rely on it play such an integral part in society. It is unimaginable to think what would happen if services like health care, security validation, point of sale transactions, stock trading, and even traffic lights suddenly stopped working. All these systems rely on COBOL precisely because it is that- reliable. Mainframe processing and COBOL programming have been historically dependable systems, thereby making the desire to move away from them minimal, especially when such systems contain sensitive information. The saying “if it isn’t broken, don’t fix it” is often applied to the COBOL predicament – although old, COBOL is not a broken, bug-ridden language and consequently, upper level management concerned with the reliability of their programs are hesitant and often resistant to migrate away from an aging language. Companies often find themselves in two situations moving into the future, which we call a rock and a hard place.

The Rock:

Option #1: Stay with COBOL as your programming language and operate it on a mainframe. This represents a low risk option. COBOL, while criticized for its age and wordiness, still maintains strong functionalities that some say are unparalleled in the programming world. Additionally, companies like IBM and Micro Focus continue to develop products that support and enhance COBOL programs and even help some colleges offer COBOL courses.

However, under this option companies face impending shortages of developers to enhance and maintain their systems, and increases in labor costs due to the smaller supply of said developers. Additionally, mainframe costs increase annually due to increasing complexity and maintenance. This option, while costly, is a predictable alternative because while companies will need to plan for an increasing budget, they know their system will continue to perform well.

The Hard Place:

Option #2: Replace COBOL with a more dynamic coding language. This represents a high risk alternative. When one considers the process of legacy conversion, risks grow exponentially. This involves analyzing business rules embedded in the code, choosing the appropriate migration language, implementing migration, integrating new code with the existing mainframe or switching from a mainframe to a new system, and testing for bugs and performance. Accurately translating the meaning behind the source language into the syntax of the target language is very difficult. Although some code conversion is advertised as automated, extensive manpower is required to ensure the output from the target language is the same as the source language. To ensure truly successful conversion, the ideal conversion process would be one that is custom tailored for the specific software being translated, which is extremely expensive. COBOL may contain capabilities not supported in the target language, and vice versa, both of which can result in lost capabilities and an inefficient translation. Additionally, contemporary languages are built to run on other systems such as servers. Migrating from COBOL to a modern language will most likely require a systemic architectural change. This process, although lengthy, can be successfully done. Systems like the New York Stock Exchange’s Euronext migrated from COBOL, stating the changing environment of their system along with the obsolescence of mainframes in the trading industry drove them to adopt a new processing platform and server system.

This alternative has clear cost drivers with extensive labor costs for converting code, code analysts, system integrators, and system testers. These costs don’t include the risk involved in switching virtually every part of a system’s code. All of these components, and the costs associated with them, make the legacy conversion process one that is high cost and risk with conditionally successful results.

What Now?

Looking at these options, it seems as though both choices lead to huge expenditures, and ultimately don’t provide a feasible solution. Due to the prominence of organizations that so heavily depend on COBOL and their risk-averse attitude, it seems the obsolescence of COBOL is not in sight. However, the current average COBOL developer will be looking to retire within the next twenty to twenty-five years. This begs the question, how can these organizations, while maintaining COBOL find a way to look at this foreshadowing and act proactively? It is clear that the highest cost driver is the cost of waiting. Not planning an acquisition strategy to handle the aging of COBOL and its developers leads to escalating costs. Every year seasoned COBOL developers retire, and their knowledge about the systems they helped create retires with them. Organizations running COBOL need to be proactive about this diminishing institutional knowledge, so when the time comes to migrate away from the ever-fading language they will be prepared, with the knowledge of half-century coding transferred to younger developers and a plan that will guide them through the process of making those paramount decisions.

—

¹ Trikha. “The Inevitable Return of COBOL.” HackerRank.

References:

Anthes, Gary. “Cobol Coders: Going, Going, Gone?” Computerworld. Computerworld Inc, 9 Oct. 2006. Web. 9 July 2015. .

Asay, Matt. “All The Rich Kids Are Into COBOL- But Why?” ReadWrite. Wearable World Inc, 14 Sept. 2014. Web. 9 July 2015. .

Mitchell, Robert L. “Cobol on the Mainframe: Does It Have a Future?” Techworld. ComputerWorld US, 15 Mar. 2012. Web. 9 July 2015. .

Trikha, Ritika. “The Inevitable Return of COBOL.” HackerRank. 2014 InterviewStreet, Inc, 06 July 2015. Web. 9 July 2015. .