Bankers seem to have lots of questions right now about the continued relevance of COBOL in their organizations. “When are we going to dump this old COBOL software and go to something modern?” “How can our bank compete using this old language, initially developed in 1959?” “What’s the matter with you, Mr. or Ms. CIO, that you haven’t moved us into the modern world?”
Our Gonzo take? Bankers, get over it! COBOL will be the most-used programming language for business applications, and for banking specifically, for the next 25 years, just as it has been for the last 50 years. While new technologies and tool sets will continue to proliferate around core COBOL applications, modern technology is not a “magic wand” that can instantly replicate the rich functionality built up over decades on banking systems. For those ready to call me an obsolete techie who’s out of touch with the times, I ask you to hear out my case for the immortality of COBOL.
Just a few days ago, I celebrated the 43rd anniversary of the day I went to work for a medium-size bank in Austin, Texas. This bank had a small data processing operation in the basement, and programming was done in Assembler language, very much a second-generation computing environment – incredibly detailed, arcane codes were needed just to fire the damn thing up. We had no operating system – to initialize a program, we literally pushed buttons on a console that read in one and only one punched card. On that card were the machine language instructions to read in a few more cards, which in turn had the instructions to read in the rest of the program, which was all on punched cards. Can you say Neanderthal? Yet at the time, this process was state of the art.
Genuine Artifact #1
Soon after I joined the Austin bank, so-called third-generation machines and languages came to our world. The programming language we used was COBOL – COmmon Business Oriented Language. COBOL had one compelling advantage then, which still exists today: it is easy to learn. It is a simple language that encourages a straightforward coding style. Every variable is clearly defined in detail, as are file formats. We routinely took staff with little or no computer training and had them productive from a computer programming perspective inside of a few months. And COBOL absolutely enabled staff to focus on the complexity of the business applications, not the complexity of the language.
What our bank found back then was that taking an experienced loan operations staff member, teaching him COBOL and then asking him to help program a complex loan business process worked extremely well. We also found that we could take computer operations staff, give them a 30-day training course, and then imbed them in user departments to learn the business processes before bringing them back to program some of those business processes. Sounds a lot like a Web-based workflow developer today! As long as we gave developers adequate time to work closely with business unit staff and thoroughly understand their processes, the programming was not difficult.
Genuine Artifact #2
Another major factor that will keep COBOL relevant for a long time is that basic banking processes, once programmed, can be easily replicated. All of the business logic that has been developed in COBOL over the last 50 years is, for the most part, still relevant. Virtually all of it has already been ported to newer machines and newer environments along the way (such as structured language constructs, object-orientation, visual programming environments, calling conventions from non-COBOL languages such as C, support for execution within Microsoft’s .NET environment and Java, and XML generation and parsing).
One of the bigger success stories in porting banking software from one platform to another is Fiserv/Premier’s movement of a solution originally developed for a Unisys MCP environment to an IBM iSeries environment. Arguably, this would not have been possible with any language but COBOL because moving COBOL code from one platform to another is several orders of magnitude simpler than re-writing it in any other language.
Some COBOL code is relevant in different situations than that for which it was developed. The date calculations that figure out how late a loan payment is can be easily applied to figuring out if a safe deposit box payment is late, for example. The steps needed to accrue interest receivable on a simple interest loan can, with only minor changes, also be used to accrue simple interest payable on a savings account. Once a routine has been written and de-bugged, it has value for many, many years – and there is little payback in re-developing that logic in another language.
In the interest of equity, it should be noted that COBOL has weaknesses, some true and some perceived. It is verbose – COBOL code requires longer data names and procedural descriptions. This is because it was designed to be self-documenting. With proper training, any additional verbosity from COBOL is offset by legibility and ease of maintenance.
Had this 50-year wealth of banking automation been developed in some other language, then possibly that language would have survived, just as COBOL has. But because COBOL was (and still is) easy to write, developers can be productive with less training and can spend more time solving business problems and less time learning the language.
In 1997, the Gartner Group reported that 80% of the world’s business ran on COBOL with more than 200 billion lines of code and with an estimated 5 billion lines of new code produced annually. The fundamental constructs of the banking software world haven’t changed much since then.
Genuine Artifact #3
There are many external factors driving discussions among bank techies regarding the geriatric age of COBOL including:
But whatever the reason for the buzz, what we do know for sure is that some of the ongoing utility of COBOL is not due to the language at all (other than its inherent flexibility) but rather due to the ability of the mainframe world to adapt to and incorporate client-server, Web services and desktop computing innovations. For bankers, it’s about simplicity, ease of use, and rich functionality, which COBOL has in spades! New Web services and database tools have great potential for helping banks perform better. Bankers should let up on the COBOL-bashing sound bites and focus on the capabilities new and old technologies can deliver to support business goals. It’s all about the functionality!
-bMcF
A Technology Assessment from Cornerstone Advisors can assist your organization in determining whether its current technology solutions are adequate to handle future growth.
Among the many benefits of the Technology Assessment, you’ll gain:
Contact us today to put our highly skilled team to work in securing the success of your organization’s future technology.
If truly 80ish% of the business world runs on COBOL, where are all the programmers? I’ve never personally met one. How is all this code maintained?
COBOLers out there, give us a shout out! Are any of you under age 30? What region of the country are you in? Thanks for humoring me.
I am not under 30 but will never have a problem getting a job. The fact that there are not alot of COBOL programmers under 30 is one of the reasons large banks have to go off shore. Stop being a computer snob. There is enough IT work out there to go around!!!
Agreed – people with good logic skills and the ability to comprehend a business process and then develop software code to solve that business problem will always be needed, no matter the language. COBOL is just particularly easy to learn–as is RPG (but to my knowledge RPG is IBM-specific) and COBOL had/has more cross-platform applicability.
As for going off-shore? That’s about cost–those folks work really cheaply.
I’m a Mainframe COBOL programmer Western New York and I’m 27. COBOL doesn’t really need to be “maintained” in the sense of updating to stay current…The mainframe is excellent at backwards compatibility, so code that was written in the 70’s can still run, although it would run in a 24 bit addressing mode, unless recompiled. Maybe you don’t know any COBOL programmers because the code is so well written, that it doesn’t need any “maintaining”. Why not use mainframe/COBOL in a large enterprise environment? There is no other platform available that can measure up as far as RAS…Reliability/Availability/Scalability.
Well said! COBOL is easy to learn and easy to maintain, which is why it has been so durable.
“Well said”?!!!
That is the biggest load of rubbish I have seen for a long time. 🙂
Without wishing to be too hard on Sean, who has, as yet, a limited career experience, (see what you think in 30 years, Sean :-); I wrote COBOL for a living all over the World on many different platforms and in many different “cultures”, for around 27 years, so we have one number in common :-)) Not being personal, but I can’t let what you said slide and especially not Bill’s response (he should know better :-))
The MAJOR cost in using COBOL is the cost of maintaining it, NOT writing it.
It is so verbose you must wade through thousands of lines of it if you need to make a change. It is MUCH harder to visualize and understand code that covers pages than code that takes a paragraph, even if that paragraph is complex and powerful. (You take it apart step by step just like you do with any language, but there is MUCH LESS of it so it takes less time, and that means it costs less money.)
Furthermore, you change the COBOL, being fairly sure that your change won’t impact anything else in the program, and it doesn’t. But next time it runs a different program falls over for a not-immediately-obvious reason which, on investigation turns out to be because a downstream feed file was affected by the “safe” change you made.
(OK, it is a contrived example, but anyone who has spent time maintining cobol knows what I’m talking about… :-))
With encapsulated objects this simply can’t happen. You DON’T change the objects! (You might temporarily override a method to see if it is safe, but isolated, encapsulated code is much easier (and SAFER) to maintain that huge monolithic code that has everything (IO, Business Logic, Presentation layer, etc.) all integrated into it as a matter of course.
It is the COST OF MAINTENANCE which has been one of the major factors in leading to the decline of COBOL. In my own Company I have seen a 70% saving in maintenance costs since we moved to C#). Apart from that, changes get implemented much quicker and we use Agile style quality control and development, with time boxed iterations as standard development practice.
Functionality is designed, then software is evolved to implement it. You probably COULD do something similiar with COBOL, but nobody does, and OO programming lends itself to this.
As I noted elsewhere, things have changed a lot since the 60s… 🙂
Unfortunately, you’re confusing the quality of the code with the language it is written in. It is possible to write clean, well-structured code in COBOL (as you admit) and it is also possible to write bad code in any “modern” language including C#.
I might also observe that it is now common practice in banking to test new code before it goes into production (in whatever language it is written) so nothing “falls over” the next time it runs. Furthermore, “monolithic” has to do with how it was written as well as the language. It has been possible–and good practice–for many decades to structure code and segregate IO, Business Layer, etc. so that it is easily maintainable. It’s nice to have help from the language, agreed, but it’s not mandatory if the system development life cycle process is/was well-done–as is true in most modern US banking environments.
As a language for new development, an argument MIGHT be made that COBOL is declining. As the language used to develop most US domestic processing for loans, deposits, credit cards, etc., the object code from which runs every day in most domestic banks, it is still COBOL (with RPG coming in a second for the “community banking” platforms such as Jack Henry Silverlake, Fiserv Signature and Fidelity Horizon).
Change may be just over the horizon, but it ain’t here yet for the US domestic software world.
Bill.. I lived in Austin during the 60’s and 70’s. Used to take my punch cards down to UT and feed them in the card reader. Number one rule, never drop the deck!
Which bank did you work for during that time? Austin National was the big guy in town then.
I worked at City National, later First City, from 1969 until 1992 with one year away at EDS. Austin National was the bigger bank, but by the mid-80’s we had the biggest data center–we had bank clients from Dallas to Corpus Christi to San Antonio to San Angelo. We made a lot of $ for our bank until the Houston First City gang sold the data processing business to EDS to raise capital–those geniuses sold a business throwing off about $7 million/year in cash for a one-time $4 million payment.
I did the punch card thing, too, down in the basement of the BEB–Fortran programming for, I think, Statistics 310. It was the easiest A I ever made, but I had an unfair advantage…
Me…, I started with FORTRAN (in the early 80s) – and wish that I had COBOL. As the first huge IT bubble was bursting and I was finishing an advanced degree in IT, almost none of my colleagues got good jobs in IT – except for the woman that had been a COBOL programmer and found a job writing Visual COBOL.
Just because you don’t see many kids trained to maintain mainframes, doesn’t mean that they won’t be needed. Same with COBOL.
I did quite a bit of FORTRAN work, too, in the early 70’s. Compared to learning FORTRAN, COBOL was a piece of cake. And both were way easier to learn than assembler.
cold, rainy day and now, nostalgia! 45 years ago i started not in banking but at a large Electrical Utility, learned assembler, autocoder, all in order to convert to COBOL. Of course, RPG, too (not II).
The reason you don’t meet any cobol programmers is because they probably just don’t want to admit it, but they must be out there!
They’re out there, but in the banking space (particularly the community banking space) the code is developed by the vendors. I assure you there are COBOL coders working at Fiserv and Fidelity (and there are definitely RPG coders at Jack Henry and the Signature business unit at Fiserv!).
I was a high school freshman at Austin Reagan 43 years ago and introduced to COBOL while at UT. I quickly changed my major from data processing to marketing when I started dreaming in COBOL code.
My job duties changed in 1989 and I’ve done no COBOL coding since then, but I dreamed about COBOL code for along time after that. And I still occasionaly use very nearly identical processes for some occasional specific problem-solving calculations in Excel. How sick is that?
As someone who started working with COBOL in 1967, I was interested to read Bill’s thoughts on this. But there are some serious flaws in the argument, and I was suprised to see the old Gartner figures being trotted out as if they were Holy Writ when even Gartner have since acknowledged that they got this wrong.(It is just not possible to calculate how many lines of COBOL are extant in any meaningful way and it doesn’t matter anyway. Automated processes are now available which are ripping through this codebase and the backlog gets smaller every year. Many are using automated tools to move to Java, others are refactoring their COBOL into Classes that can be re-used and run with new Classes developed in new languages. The level of understanding and the techniques available to programmers today is a far cry from what we had in the 1960s. The world has moved on and so has Computer Science.)
Yes, COBOL is easy to learn (so are most modern computer languages once you understand the basic principles of Classes and Objects), yes, it documents itself when well written (but so does every other language if you add notes, and professional programmers do…), but beyond all of this is the fact that COBOL just doesn’t cut it when it comes to networked applications.
The days when source code was king (so clarity of self documentation was important) are long gone. These days we use Object instances of a Class to do stuff and we write those classes in whatever language is appropriate (even COBOL, occasionally…), OR, we buy them in as encapsulated functionality. It is the FUNCTIONALITY that matters and THAT is delivered by OBJECT code. We encapsulate functionality into Classes and re-use them over and over just like Lego blocks. Small is beautiful and the days of monolithic COBOL programs with thousands of lines of source code to wade through are gone for most modern enterprises. It simply costs too much to maintain. (And it is highly error prone and time consuming…)
Rooted in a 1960s paradigm of centralised processing, with no facility for interrupt driven processing (COBOL programs decide when they will do IO which is fine for batch processing but hopeless for interrupt driven programming – if someone clicks a mouse you better respond NOW, not when the next READ in your cycle comes round…), COBOL simply missed the Object Oriented Programming boat. OO support was bolted on to (some) COBOL compilers and it was a magnificent feat of software engineering, but the significance of why it was necessary was lost on most of the COBOL community.
The world has voted with its feet and moved on. Many Banks have already moved their legacy COBOL to modern networked systems that can distribute information around the company and the World in a heartbeat. Others are in the process of doing so. The Internet is becoming woven into the fabric of business and society and COBOL is not good at it.
You CAN do it in (OO) COBOL but it is easier to use languages that were designed for that. You CAN start a fire by rubbing two sticks together, but why would you when you have a Zippo…?
COBOL is a dead language and currently around 30th in the list of languages actually used for commercial software development. For decades it was either number 1 or in the top 3.
There IS still a significant investment in it and many companies will want to leverage that investment for as long as they can. You can do this by wrapping the legacy into Classes, making it part of SOA or a Web Service, or simply using it in Object form to play nicely with objects in other languages on a level playing field like .Net.
If your business depends on Batch processing, there is still a place for COBOL, but modern systems remove the need for Batch processing altogether. Modern Relational Databases and Data Warehouses/Repositories run parallell subsystems which do the work that was once done by overnight Batch. Systems are designed to model the real world in real time; “catch up” processing is irrelevant.
We can agree “Its all about the functionality” but after that we diverge… widely 🙂 It isn’t about COBOL bashing (I love the language, but I’m not blind to what else is available…); it is about using the best tools for the job.
After migrating the COBOL codebase of my company to C# around 5 years ago I can say I only wish I’d done it sooner. These days I’m happy to be helping others make the same transition. Instead of paying thousands of dollars for an expensive COBOL compiler and maintenance/support, why not use a FREE .Net compiler and spend the money saved, on training your staff in modern programming techniques?
And yes, I do know a bit about Banking, having worked as a consultant to some of the World’s household name Banks. They do not need the cuddle blanket of ancient COBOL code, they just think they do. Gradually more of them are waking up and a new generation of managers are moving in who expect more and won’t let The Waterfall and traditional COBOL development methodologies stop them from getting it.
COBOL should be allowed to die with dignity.
Well, we agree that FUNCTIONALITY is what matters! But as for the rest of that discussion, as someone famous once said, everyone is entitled to their own opinions but everyone is NOT entitled to their own facts.
First, the statement that there is “no facility for interrupt driven processing” is simply factually incorrect and has been for a couple of decades.
Second, I need to clarify that I am talking about the US domestic banking software world in this discussion. I can’t speak to New Zealand, other than to say that the offshore solutions that have tried to make it in the USA have for the most part been dismal failures–the functionality isn’t there (at least not yet).
In the US banking world, COBOL is alive and well and will be for some time. There’s no doubt that the newer languages have some significant advantages and are growing in popularity, but even a casual conversation with the major banking software providers reveals that one heckuva lot of COBOL runs on mainframe systems every day (and I’m including iSeries and Unisys MCP-class machines in the term “mainframe”–they have the MIPS to be “mainframe”, too).
In banking, and in banking software in particular, it is all about Cost-Benefit and Functionality. The benefits of re-writing that “ancient COBOL code” do not yet exist.
I apologize for the old Gartner figures–couldn’t find anything newer and you are correct that no one really knows. But from discussions with banking software providers there is no doubt that most of the code in the banking world is still in COBOL–and I hear 80% bandied about a lot but that is a subjective number that might well be off, low or high. The bottom line is that there’s been no reason to re-write all that COBOL–the Cost-Benefit just ain’t there yet.
I’m going to stir the pot even more and observe that there is also a heckuva lot of RPG out there in the banking world and it will also be around for a long, long time. If we add the RPG code to the COBOL code, probably 90% of the banking world lives in “legacy” code.
A good and mostly fair response, Bill.
One thing though, please don’t assume, because I happen to be currently living in New Zealand, that my comments pertain only to the New Zealand Banking world. (Although, as far as IT in general goes, both New Zealand and Australia have some excellent state-of-the-art systems implemented, both in Banking and in Insurance and other traditionally mainframe areas…)
I lived and worked for over 30 years in Europe and occasionally in the USA. I know there is a large commitment to fossilized mainframe systems and I understand (and agree) that much of it is about cost to replace. (There is also the old “if it ain’t broke…” syndrome) It is true too that the old systems contain proven code and the platforms they run on are reliable and stable. But that doesn’t mean people will continue developing in COBOL. (And they are not; don’t take my word for it, check any job boards and see what demand there is for COBOL guys. It isn’t something young people need to be making a career out of.) COBOL with us for 50 years? I don’t think so.
I think the main point where we diverge about COBOL is that I don’t think the procedural paradigm COBOL represents is a good one for a modern Networked world. It ISN’T about the language; I used it and loved it for many years. But the Network needs Objects and Layers, and COBOL, generally, is not good at that.
I accept your points about proper testing before things go live and I’m pleased to note you live in a world where production never crashes and nobody gets called out of bed at 3:00 am… 🙂
Obviously, we probably are not going to agree, but I respect your view and appreciate the honest and fair way you have defended it. (I hate it when these discussions descend into flaming and ad hominem attacks and there is no real attempt to discuss and examine issues which are debatable.)
My final point is this:
The world has changed much since the 1960s and so have the people who work wth computers. We have a generation of users now who are more computer literate than they have ever been. They don’t need to to make sacrifices to the Priests of COBOL in order to get IT systems implemented (as they did in the days when COBOL was the only game in town) and if they are not getting proper service from their IT departments they will meet their own requirements with spreadsheets and databases, or they’ll move to packages and outsourcing where they CAN do that. They EXPECT more timely delivery, they EXPECT better and more comfortable user interfaces, and they EXPECT to be involved in major application development.
A whole generation of people who see computers as familiar as their telephones are on the way.
I don’t think COBOL is going to cut it for them.
Regards,
Pete.
Just so you won’t think I’m a total Luddite, here’s a link from an article I wrote nearly 5 years ago on Feb. 27, 2007:
https://gonzobanker.wpengine.com/2006/02/does-architecture-matter/
I agree with you on many (maybe most) of your points–I just don’t see the major vendors investing the $ to re-write the COBOL code that’s out there. The cost-benefit isn’t there (yet) and no bank should change systems solely to get away from COBOL.
I love Cobol not touched it in 10 years. Our core platform never has used Cobol. Anyone designing a new system today would not even consider it (Fiserv’s replacements for the platforms do not). The reason it still exists in our industry today is due to the cost to replace it. The 80 percent is more like half that. That number was before y2k.. While there exists object oriented Cobol there ares still more features and flexibility with Java or C#.
I am a Cobol online solutions developer and I would attest that Cobol language still dominates internet/web business applications. I incorporated pure Cobol code into several web technologies (ASP and COM+, Silverlight, JSP and EJBs, Ajax, jQuery, Javascript, HMTL, XML) and it is working. Since the proliferation of the internet, I never looked back doing GUI-form (or DOS) type programming… but with browsers and mobile devices instead.
Really glad that Cobol worked its way to be on top and bringing its technologies and easy-to-learn computer “business” language to online solutions. Kudos to Admiral Grace Hopper.