The future's bright ... the future's Cobol

Cobol may not make headlines much these days, with technologies such as Java and .Net viewed as the glamorous, contemporary platforms and Cobol seen as legacy code. Stephen Kelly, CEO of MicroFocus talked to our sister publication, Infoworld, about how the language has still got a future.


I know that Micro Focus focuses a lot on Cobol and application modernisation and things of that nature, but when I read the online Micro Focus introduction that explained what the company is about, there's no mention of Cobol there. Why is that being obscured?

Yes, that's a good question. I think in terms of what we tend to be doing a lot now for some of the big companies we work for, and we're deployed across about 90 percent of the Fortune 100 companies in the world, a lot of that historically has been Cobol. But more recently, in the last year or so, particularly, there's a lot of interest in our application modernisation and towards modernisation solutions. [We have been modernising applications for use in] more contemporary architectures.

Cobol has been around for years and we just don't hear a lot about it. We hear about Java, we hear about .Net and Visual Basic, but we just don't hear a lot about Cobol. What's going on there? How pervasive is Cobol and how important is it still these days?

There was a big wave probably after Y2K where a lot of CIOs thought they'd switch their Cobol systems off, and there was kind of a bit of a rush for a year or two towards things like Java. But what we've found, certainly in the last three years, is there's a lot of pressure both from the CFO office and the CIO office to say - we've got to get a lot more value out of the applications that were already built and we've got to get a lot more value out of the business processes and business rules that are embedded within these applications. The reality is, about 70 percent of the transaction systems around the world in run on Cobol. So a huge amount of code base is based around the language. And there are some compelling reasons why we could take those applications forward, put them into contemporary architectures, web-enable them, embrace them in web services and just make them look [to be] very modern applications and yet protect all the investments made in the past that have business rules, business process, and applications code ... We've got a lot of customers in retail and financial services that have taken their core Cobol systems either off the mainframe and put them on contemporary platforms like Linux [or] .Net and browser-enabled those applications to make them much more intuitive, rather than [rely on traditional] green-screen technology.

Why has Cobol been pushed to the background in favour of Java and .Net? Is it the object orientation? What do those languages offer that Cobol apparently is not offering?

I think the reality is more complex than that, because you find a lot of developers tend to be cross-language-capable. So, if you're a Java or C# developer, to actually do or become productive in Cobol, only takes two or three weeks in reality. It's not a binary choice to ask, is it Cobol or is Java? And even what I've found going around some big financial services companies in the US and Europe and public sector, there's a lot of pressure from CIOs to say - we've got so many Cobol developers and we've got a lot of Cobol applications and investment, and what we're seeking to do is get more value out of that. Definitely 10 years ago, if you'd ask all the CIOs around the world they would have said - we're going to switch Cobol off within the next five years. And we sit here today and there's still over 1 million Cobol developers out there. And it's still running 70 percent of the transaction systems ... If you're going to talk to CIOs, they're way more pragmatic about a heterogeneous language, but they're much more concerned that they want to take their enterprises towards modernisation but also they're much more animated around architectures like SOA ... [Lately], there's not a lot of pressure to do rewrites from Cobol. There used to be. Certainly when we were coming out of Y2K, there was definitely a perception five, six years ago that the world would be completely object-oriented by now. I guess it would be all things like Java, it would all be things more recently around things like AJAX and XML. That's just not materialised. And the reality is that most core business systems are still written in Cobol.

Can you talk about your application modernisation and migration strategy?

The overriding element is what is modernisation? We've touched upon it in terms of moving core applications into modern architectures and we've talked about a couple of examples of that. The migration strategy really is where there's a lot of pressure purely based on cost reductions [and getting] more efficiencies [by] moving some of the mainframe applications running on the big mainframe farm down to Linux or even Windows. Now again, it's not a binary decision, it's not a religious decision, because what we've got is a lot of customers, even folks like Wachovia, who started off looking at just moving the development of the mainframe applications onto open systems platforms. And then you can do all the testing on the open system platforms as well, and then you actually send the code back compiled back to the mainframe.

A lot of customers say the best place to run really high-throughput transaction systems 24/7 that [offer] reliability, availability, scalability, is on the big mainframe. But there is a compelling reason where they don't want to have to put up with batch cycles and only getting machine time at certain times of the day for their developers. So they basically take a mirror image of the application and then on that do development on a Linux box, test it on the Linux box, and then ship it back up to the mainframe for maybe final tests and then run it. And then they keep the integrity of their systems perfect. [This procedure] allows them to reduce their mainframe farm and they get much higher availability and throughput in terms of application development.

Can you talk about the Hal acquisition and what that means for Micro Focus?

What the Hal acquisition gives us is [when] we talk about modernisation, the first question you get hit by a CIO, is - what do you mean by that? And the first point of that answer is you're going to get a big financial services company, then one thing we'd say is, tell us what applications you've got in place. And the truth is they've probably got 300, 400, 500 business mission critical applications in a combination of languages from Cobol, PL/1, even things like Assembly and stuff like that. But [there are] also a lot of Java, C++ and other contemporary languages. But very rarely do CIOs have any real intelligence about lines of code, who the developers are that developed them, the documentation, what business rules are present within the different applications that are common across applications. What [Hal provides] at the simplest level is almost like a CIO dashboard of all the enterprise applications. It's almost like an outlet.; so it gives a complete encyclopedia to the CIO.

"Recommended For You"

Should universities offer Cobol classes? Universities fail to offer essential programming skills like Cobol