Dancing with the Devil, Converting COBOL to C#
COBOL or Common Business Oriented Language is a 60-year-old business language that still powers a substantial slice of the world’s most critical business systems. In fact, COBOL is unique in its endurance beyond what is considered the average lifespan for software development languages.
Support opening statement: As we write this article, we’re helping our client, one of the largest real-estate tax processing companies in the world, get off the mainframe, and get out of the business of maintaining COBOL code. If you are running a COBOL mainframe, schedule a call with us. We are here to help.
COBOL or ‘Common Business Oriented Language’ is probably older than you are. It’s a 60-year-old business language that still powers a substantial slice of the world’s most critical business systems. In fact, COBOL is unique in its endurance beyond what is considered the average lifespan for software development languages.
Why?
The answer is a bit more multi-faceted than you may think at first.
On the one hand, COBOL, the programming language, has evolved from a mere language or a means to an end, to an institution. As Serdar Yegulalp, in his article published on infoworld.com correctly notes, “massive COBOL codebases are still in use around the world, many of them running almost exactly as they were first created.”
Reuters recently came out and said that 43% of all banking systems were still built on the COBOL framework, 80% of in-person transactions use COBOL, and 95% of ATM swipes rely on COBOL code. Additionally, there were 220 billion lines of COBOL code still in use in 2017. Consequently, based on this discussion’s opening comments, it is reasonable to assume that three years later, there are still 220 billion lines of COBOL code even in use today. 220 billion.
The trade newspaper, American Banker, discovered that, in 2014, 92 of the top 100 banks in the USA were still using mainframe computers, as were 71% of all of the Fortune 500 companies. And the IT department at the Bank of New York Mellon had to maintain about 112,500 individual programs or 343 million lines of code.
On the other hand, the age-old adage rings true here, If it ain’t broke, don’t fix it. This is particularly true for the banking industry. COBOL is so entrenched in the modern banking systems, and because these systems must run correctly 100% of the time, it is difficult to transition to a new or more modern language. But the reality is that most executives have their heads in the sand, and have no idea that their systems are indeed broken. They don’t seem broken to most people using them, but they are. They are broken because They teeter on the edge of a cliff - A cliff of time and human intellectual capital.
The disadvantages of retaining legacy COBOL systems
A legacy system is defined as an outdated computer system that is still in use today. Much of the hardware and software technologies still in use are now obsolete compared to the latest Information Technology trends. Consequently, the systems are no longer as functional as they were, and they have become increasingly difficult to maintain as time passes by.
Both hardware and software maintenance are expensive. There is a shortage of replacement parts for the older mainframes, which drives up the costs, and because there are very few programmers who can code in COBOL, the software maintenance costs are high.
The average age of COBOL programmers is now between 45 and 55 or 60 years and older with younger developers showing zero interest in learning COBOL. They are more interested in learning languages like C#, Python, and Java or JavaScript.
Statistics quoted by wiredelta.com show that the US finance industry spends 80% of its IT budget on legacy maintenance, with $300 million annually on software updates to legacy COBOL programs to ensure that this software meets the required standards.
Over time, the cost of maintaining legacy systems can run into millions of dollars, as depicted in this illustration.
Secondly, security and the adoption of the latest cybersecurity best practice methods are challenging to implement on legacy systems. However, in today’s world, it is vital to prioritize cybersecurity implementation and maintenance programs. Otherwise, organizations run the risk of having their systems hacked and losing valuable and sensitive data.
Thus, the only conclusion that can be drawn is that it makes sense to convert legacy systems from COBOL to C#.
COBOL versus C#
At the outset of this discussion, it is essential to note that converting COBOL to C# is about risk management. Not only does the software code have to be upgraded to C#, but the business model must also change from a traditional mainframe-based model to a modern, cloud-based solution.
A graphic representation of the traditional versus modern banking model is shown below.
These diagrams demonstrate the challenges with adopting the modern banking model while still using legacy mainframe systems running COBOL software programs.
There are many differences between COBOL and C#, the primary one being that COBOL is a procedural language designed in an imperative way. The code or commands are written and executed one after another. Juxtapositionally, C# is an object-oriented language where virtual entities or objects are created to mirror real-world objects. C# is also an event-driven language and is structured in a circular manner where objects are created and destroyed when they are no longer needed.
The primary difference between the two languages is demonstrated in the following source code examples:
COBOL
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
PROCEDURE DIVISION.
DISPLAY "Hello, world".
END PROGRAM HELLO.
C#
public class Hello
{
public static void main(String[] args)
{
System.out.println("Hello, world!");
}
}
The COBOL program executes by starting at the top and working its way down through each line of code, step-by-step, and terminates when it reaches the ENG PROGRAM HELLO statement.
On the other hand, the C# code will only run if an object is created from the Hello class. Secondly, the C# program can create as many Hello World objects as needed, each with a different name. When each Hello World object is called, it navigates to the code displayed above, creates the object, and prints out the “Hello, world” statement. Once this statement has been executed, the program returns to the calling program. The best way to describe this scenario is by looking at the following diagram.
Converting COBOL to Modern Languages
At this point of the article, let’s assume that the decision to convert the legacy COBOL code to C# has been made; the next point to consider is how to convert the code.
The good news is that there are several options to choose from. The most time-consuming option is hiring a programmer who can code in both languages to transcribe the programs, line by line, from one language to another. Not only is this option going to be extremely time-consuming with a virtual guarantee that this project will never finish, but as described above, the basic constructs and paradigms of these languages are so different that manually converting software programs developed in a procedural language to an OOP (Object-Oriented Programming) language is a huge ask.
Thus, the only alternative is to consider an automated tool designed by one of the vendors available in the marketplace. These tools transform COBOL to C#, implementing C#, and OOP best practice methods. The companies offering this service provide specialist consultants who are knowledgeable, skilled, and experienced in both languages and the functioning of the automated tool utilized.
It is vital to sign a contract with a vendor who offers an automated COBAL to C# conversion service, not only because they are proficient in the use of the code conversion tool, but a manual code review process must form part of the project to ensure that all of the legacy COBOL code is converted correctly. Converting to a modern language typically follows this path:
- Assessment and Planning: Evaluate COBOL code, identify scope.
- Choose Target Language: Select modern language (e.g., C#, Java).
- Automated Conversion Tools: Use tools for streamlined conversion.
- Manual Refactoring: Address conversion errors, optimize code.
- Testing and Validation: Comprehensive testing to ensure accuracy.
- Integration with Modern Tools: Incorporate modern frameworks, APIs.
- Training and Support: Provide team with necessary skills.
- Deployment and Maintenance: Deploy, monitor, and update system.
But without the right partners, you’re playing with a multi-year plan that could slip into disaster on the books. Our team can help with this. We’ve done this before.
What to look for before signing the contract with a COBOL-C# conversion service provider
The last part of this discussion is to consider what to look for before signing a contract with a COBOL-C# conversion service provider to ensure a high chance of success.
As inferred several times throughout this discussion, a COBOL-C# code conversion project will be a monumental task. It can take years, mostly if unrealistic expectations are set at the outset of the project.
Thus, it is essential to make sure that the service provider that your company chooses to go with is professional, sets clear expectations based on a thorough understanding of the volume and complexity of the COBOL code, can unquestionably elucidate the end goal as well as the step-by-step process to reach this goal.
For instance, the decision where to migrate a traditional banking system running on in-house mainframe servers must be clearly stated, including whether the new system will run in the cloud on AWS servers, using the AWS architecture or stack, from the data storage in a data lake construct, the setting up of development, QA, and staging environments, the containerization of processes, using Kubernetes or Docker, similar to the modern banking model diagram where each entity is converted into a service, and the monitoring of processes using CloudWatch to ensure that each service is optimized and running efficiently at all times.
Additionally, a useful method to utilize before signing a contract is to read use case studies and white papers. These documents will give you a good idea of whether the service provider can take on a project of your scope.
Finally, the last step to take is to ask the company for references to similar projects that have been completed. If the company is serious about working with you, they will do their best to assail your concerns. After all, the legacy COBOL code is critical to the successful functioning of your business.
Final thoughts on COBOL as the C-level exec understands it
For the C-level executive, if you want a cheat-sheet, here it is:
- Strategic necessity: Convert your COBOL to modern language or hold on to the dusty relics as they pull you over a cliff.
- Organizational benefits are not always easily measured: It’s not just the $$ of the mainframe support contract or licensing contract savings. It’s the entire org’s overall momentum and overall efficiency, and the org’s future adaptability at stake. Nobody calls to tell their spouse how excited they are about getting to work on a mainframe. It sucks. And great talent exits the organization. That’s reality.
- Workforce challenges: The shrinking COBOL developer pool is real. If you don’t acknowledge it, you’re in a state of denial.
- Cloud computing standard is reasonable to point to: Advanced analytics and decisioning models are not running archaic languages for a reason.
- Riding that wave of momentum: From the board level, to the C-level, to middle management, to all below, the transition from antiquated systems to modern systems will drive momentum and energy for a period of potentially sustained growth.
We are in a technological age where cloud computing is the answer to most enterprise software and hardware requirements. The interconnected nature of Big Data and data analytics requires that data is collected from different systems and sources, uploaded to “the cloud,” where it is loaded into data warehouses or data lakes. There is an extreme lack of application extensibility and interoperability between these legacy COBOL systems and the modern cloud-based technologies; thereby, reducing the data scientist’s ability to produce accurate statistical information. Executives who embrace and lovingly caress their 60 year-old mainframes are either 1) in denial, or 2) ignorant of the liabilities involved with their mainframes, or 3) being lied to.
