chris - Fotolia
The risks of maintaining an out-of-date COBOL system are significant, so organizations must either modernize a legacy COBOL system or transform it from the ground up. COBOL forms the core of many important systems. The organizations that use them are rightfully wary of modernization, because the costs and risks involved in transforming a central application are immense. Failure to act -- either by virtualizing COBOL or migrating it to the cloud -- could be detrimental to the business.
Many systems are rooted in legacy COBOL
COBOL is at the core of many banking and business systems; governments worldwide are heavy users. Much of COBOL -- there are some 200 billion lines of legacy COBOL code still in use -- runs on old-style mainframes, despite their high operational expenses and limited performance.
For COBOL's base of conservative users, those mainframes are a significant barrier to migration. They tend to see mainframe replacement with client-server or commercial off-the-shelf systems as too risky, at least until the new technology matures. In today's mobile-focused, graphical environment, however, the need for a bridge out of legacy COBOL has become critical, so code modules have been written to interface to the outside universe using C, .NET and other modern languages and environments.
Risks are high for legacy systems
Current IT tasks demand agility, and businesses need to evolve to match the changing market and get ahead of competitors. In the past, this seemed to require a migration from legacy COBOL to a modern language. The problem with this approach is that the COBOL app is often the backbone for company operations. The huge costs involved in the rewrite process to prove new code before it's released into production add to this risk.
There are plenty of examples of huge failures in the rewrite process. A number of government software projects around the world have crashed and burned spectacularly. This possibility makes many CIOs grit their teeth and buy another mainframe every 10 years or so. These captive customers can expect to pay through the nose, first for capital equipment and then for support and operating costs.
New tools provide virtualization options
The maturation of the cloud, coupled with migration tools, offers solutions to the captive hardware dilemma. We now have tools that transition core legacy COBOL apps from the mainframe into VMs without any major rewrite. You'll need to recompile to target the VM, but that's not a big deal compared to mass code rewrites.
Almost all of the code can move without change, though anything written in assembler will need to be recoded. With the right compiler, I/O and comms will also be identical to the old system. Things might get a bit more complicated if you're going to use RESTful I/O instead of block I/O.
Taking advantage of the parallel nature of the cloud is also a potential challenge. There are several companies, such as Micro Focus, that offer consultation on this topic, as well as with the general issue of tuning legacy COBOL in the cloud.
Making migration happen
The trickiest part of a COBOL migration to the private cloud lies in building out a virtual infrastructure that properly supports the apps. Both semantics and structure differ between private clouds and, of course, are all different from the mainframe experience. A one-to-one match won’t happen, so it's crucial to understand the differences between the original and what is possible in the private cloud. Don't expect to get it right the first time. It's critical to deploy test and QA processes to succeed with the migration.
Performance is another issue. Private clouds aren't mainframes and have much more scalability. It's critical that your app is set up to run in a multicore environment that will allow it to take advantage of the private cloud's inherent parallelism.
If the app isn't multithreaded, all might not be lost on the performance side. Some of the largest private cloud instances are powerful computers in their own right and might match or exceed a mainframe in compute power, especially if given a large dynamic RAM space and local solid-state drive instance storage. Of course, the most recent mainframes are faster too, but you should compare the 12-year-old mainframe you want to lose with the latest private cloud instances.
Legacy COBOL can be rejuvenated
All of this sounds pretty easy, but we need to step back and look at some collateral issues involved in a cloud transition. The programming staff for COBOL typically consists of long-term employees nearing retirement. They can apply changes with pinpoint accuracy because they have enormous experience with the app in use and in the company's field of business. The problem is that the industry isn't generating replacements. There are no universities or trade schools teaching COBOL; it has become the Latin of the IT industry, a dead language only good for ancient IT tasks.
The answer is to rejuvenate COBOL itself. A decade ago, Visual Basic revived Basic in a similar way through a design that worked with current coding practices. As with Basic, this doesn't initially mean changing the code itself, but this COBOL update does make COBOL easier to learn for new programmers and speeds up the process.
Visual COBOL isn't the complete answer. Organizations need to upgrade the IT processes that relate to changes, which is a considerable effort. Many legacy COBOL shops have change queues longer than a year, a timeline that doesn't meet the modern standards of agile operation.
Competitive pressure might force transformation
Even a cloud-based COBOL approach will face the competitive pressure of new technologies. Technology built around in-memory databases can easily outpace a legacy COBOL app, while GPU acceleration and massively parallel processing on the software side and much faster server engines on the cloud infrastructure side can increase the agility gap. In other words, the decision to move to cloud COBOL might only delay an inevitable move to a modern app.
The challenge for the CIO is to decide whether to modernize by moving legacy COBOL apps to VMs, the cloud or do a complete makeover. With today's Visual COBOL as a tool, that's at least a realistic choice.