MOVING FROM YOUR LEGACY SYSTEM – COBOL CONVERSION, COST AND CONSEQUENCES

BY LOGAPPS LLC

In 1960, COBOL, one of the first programming languages, was developed. 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 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 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

COBOL, used for business operations, was specifically designed for the un-savvy programmer; each action performed must be explicitly laid out, making it a more approachable yet verbose language as compared to its 1960s 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 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. Most US universities have stopped offering COBOL courses in their computer programming curricula because young developers are more focused on contemporary languages which comprise the majority of computer programming jobs see the figure above. This lack of education and interest coupled with an ever-increasing age of current COBOL developers (with a majority 45-55 years old1) has led to an enormous demographic 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. This has led to an incessant increase in the development and maintenance labor costs for organizations (with often decreasing IT budgets).

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. Health care, security validation, point of sale transactions, stock trading, and even traffic lights rely on COBOL. All these systems rely on COBOL because it is reliable. COBOL has been historically dependable making managers hesitant to move away from it, especially when the systems contain sensitive information. 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 increased 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 considering 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, 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 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.

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

WHAT NOW?

Looking at these options, it seems as though both choices lead to huge expenditures and ultimately do not 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? 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.