X
Innovation

COBOL still not dead yet, taking on the cloud

Common wisdom says that COBOL should have died years ago, but the language that sits at the heart of financial systems is still around, and making moves into the cloud.
Written by Chris Duckett, Contributor

"It's almost impossible for most people, in our day-to-day lives, to avoid a COBOL application," says Stuart McGill, chief technology officer and general manager of Borland for Micro Focus. "COBOL applications tend to be the ones we can't really do without."

Approaching 30 years with the company, it's fair to say that McGill is familiar with the ins and outs of one of the oldest programming languages around — a language that still sits at the core of the financial world.

"Normally most transactions that we go through everyday would be supported by COBOL applications, still are, have been for 30-40 years, probably still will be for 10 to 20 at least," McGill says.

For decades, COBOL has been running on the heavy iron that occupies the computational core of many banking institutions — it's a sector that is traditionally conservative and waits for the technology hype cycles to pass before extracting the tangible gains on offer. With the advent and proven advantages of virtualisation, and the acceptance of cloud as a viable platform, COBOL is beginning to move from the mainframe, and heading into the cloud.

Conceptually, taking a language that can trace its heritage back into the 1950s onto a modern as-a-service platform may seem like an exercise in futility, but McGill says that it is a transfer that is not as mind-bending as it first sounds.

"Believe it or not, it's probably easier to move COBOL into the cloud, than it is to move a C/C++ application into the cloud. It's certainly easier to a COBOL application to the cloud, particularly from a mainframe environment than a client-server, and Microsoft-based client-server [environment]," he says.

COBOL's mainframe-focused design and experience, allows for applications to focus on what it does well — transactional processing and business logic.

"A lot of the concepts are pretty familiar," said McGill. "For example, most IBM applications use CICS, which is psuedo-conversational i.e. you almost have applications that are almost RESTful in a very limited way by their very nature, whereas RESTful state or psuedo-conversational state just doesn't exist in client-server applications, that means [to take such an application to the cloud] you have to re-architect an application and therefore almost start from scratch."

"Whereas from a COBOL perspective, you almost have some of the concepts you're actually looking for already built into the infrastructure that surrounds COBOL applications and has done for many, many years. The infrastructure layers in a mainframe application are built around languages just doing processing, data is optimised through various layers to cope with huge amounts of data very quickly either in serial mode, or in some degrees, parallel."

That's not to say that COBOL is a magic cure-all that the industry has maligned for half a century, there is one area where COBOL is terrible: User interfaces. McGill says that aspect of the language has actually helped its survivability, by needing to separate the UI from the core logic, as form factors have changed over the decades, it is the presentation and interface layers that have changed, not the core processing itself.

"They would have had to change the UI, yes, and the databases would have changed, but as far as the code was concerned, they haven't been forced to make any changes at all," McGill says.

"Largely speaking, you don't really want the business logic to change that much. Rules do change, but actually, most business, if they are certainly transaction orientated, their business is the system. The bit that is unique about them is wrapped up in those systems."

"It's both good and bad, all the foibles and things that you'd like get rid of are probably in the same systems, but all the things that make that company unique are also wrapped up in that."

As the number of actors on the system grew from tens of users in the mainframe days, into the thousands during the early days of the internet, and now into the millions of users nowadays demanding instant, realtime access from a plethora of devices, the core transactional systems are coming under increasing pressure.

"In the case of Bank of China, you've got 318 million account holders, all of them wanting to hit core systems day-in, day-out," McGill says.

"What that means is that even mainframe systems start to struggle with the sheer load that's been placed on them, so one of the reasons why pretty reasonable sized corporate entities want to move all of these really important systems in the cloud, i.e. COBOL in the cloud, is they have to just to cope with demand."

"We really do start to see now, the first wave of big, really important customers, really trying to understand how they are going to use cloud for core systems delivery, and that will spur on the next generation of client-based applications"

With the move of business into the cloud, the temptation is always there to replace legacy systems with the latest and greatest languages and frameworks on offer, McGill though, has seen it all before. COBOL, he says, could have been replaced in the early transition to distributed computing or in the early days of the PC — the hardest time he saw for the language was in the days of client-server computing. After that threat, everything seemed ok in comparison, as the industry moved onto intranet and internet-focused computing before arriving at today's landscape where mobile and cloud appear to be the signposts for the future.

As COBOL and its practitioners have soldered on, so has Father Time, and its changed the way that COBOL is developed.

"In terms of guys that really know the old mainframe systems, their getting old. But they are pretty unique in one way, that their careers are typically tied around one application — they weren't COBOL programmers, they weren't even mainframe COBOL programmers, they were home insurance or car insurance application developers," McGill says.

"The big problem for most businesses is not the age, apart from the fact that they are going to retire, it's the fact that these guys are so productive. They don't need any fantastic tooling to tell them what a single line of code change actually looks like, they probably know exactly where it needs to be, can get it to immediately, make the change, and they know where all the impacts are going to be — so they are highly productive people."

At the other end of the spectrum are the younger programmers and graduates who are coming from a world dominated by Java, JavaScript, HTML, PHP, Python, or Ruby. They know lots of languages.

"The key difference is now they haven't got application knowledge, but they have got domain knowledge." McGill says. "They know visual studio, or they know eclipse, and they've got other languages."

Due to the different ways in which modern programmers work, McGill says that Micro Focus has had to take the tooling to higher levels.

"They're used to plenty of tool-centric approaches to language rather than a language approach to the environment," he says.

"The key for COBOL has actually been to make it really consumable by programmers in the new environment, and as simple to learn as possible."

Looking to the future, McGill says that due to the risk-adverse nature of institutions invested in COBOL, the shift to cloud is only getting started.

"The customers are very conservative. We've been talking about COBOL in the cloud, believe it or not, probably for five years"

"What you tend to see is as everyone is getting bored with the cloud, actually, the real stuff is just about to get on the platform — and it forms the bedrock of the next-generation of applications."

Editorial standards