Bringing COBOL Into The 21st Century

February 25th, 2015
Scott M. Fulton

Bringing COBOL Into the 21st Century

Scott M. Fulton

Banks are reluctant to break their reliance upon mainframe systems, in part due to a reliance on COBOL. Now some vendors offer tools that may help.

Though it’s generally more cost-effective to consolidate services on modern servers, many new variables can raise costs quickly. It’s a problem I covered for our sister publication, Information Week, a decade ago, and the circumstances have changed very little since.

COBOL has been the environment for financial business logic for decades. As demand for COBOL skills increases, the talent pool has nearly drained away. So banks are faced with two choices, neither of which is easy.

First, you can train existing Java and .NET developers to incorporate a COBOL-like runtime that further extends their mainframes’ service life while extending their logic to RESTful, mobile-friendly, HTML5-compliant Web services running on PC-style servers or modern virtual machines. With this option, banks may decide to amortize their mainframes on their own schedules.

Second, you can invest in software and services that effectively relocate their business logic in its entirety to a cloud-based system that pretends it’s an IBM 3270 or something like it. This is for banks that are ready to cut the cord as soon as possible, given the increasing maintenance costs of their older hardware.

Option 1 is championed by Micro Focus. It produces a series of development tools called Visual COBOL that can extend Microsoft Visual Studio 2012 or VS 2010 (the environment for .NET developers) or Eclipse 3.7 Indigo (the IDE of choice for Java developers).

“Much of the COBOL that is out there today is procedural COBOL, the traditional way in which programs were defined and created. For many reasons, they continue to run in that same space,” Ed Airey, Micro Focus’s product marketing director, told me. Visual COBOL integrates into existing development environments (IDEs) with the objective of giving developers a path for modernizing the old code, to run in new environments, but at a pace that the organization can set for itself.

The alternative
Option 2, by comparison, is straight out of science fiction. A two-year-old Fremont, Calif., startup called Heirloom Computing – comprising some former Micro Focus talent — has built a platform-as-a-service called Elastic COBOL. It’s designed to run COBOL in its pure state, including the 1970s variety. Once a bank’s business logic is transitioned to Elastic COBOL, it thinks it’s running in its native environment.

“Our first tenet of Elastic COBOL is 100 percent compatibility,” Mark Haynie, Heirloom’s chief technology officer, tells me:

So if you move an application from a mainframe to a private cloud… in your datacenter where you have card key access, and you make no changes in that application, the default view when you connect to that OLTP app will be a green-on-black, 24×80 screen. It’ll be inside of a Web browser, but the browser will be protected through RSA’s PKI technology, so it can be restricted to a particular set of IP addresses.What’s the point? Haynie says banks need a new starting point, before they can even begin to consider modernizing their apps. The path from modernizing a “rehosted” COBOL application to a RESTful Web service upon which developers can build an HTML5 front end is shorter than trying to modernize COBOL where it resides today.

Either way, any effort to modernize banking systems so that mobile and Web services can be built around them, will require developers who understand COBOL’s unique and certainly quaint eccentricities.