COBOL is retiring – what are the implications?
Published Wednesday 31st May, 2017 by Paul Holland
In 2018 we will be celebrating the 50th anniversary of COBOL becoming an ANSI standard programming language*. More importantly, the majority of people who program in COBOL have working lives that span a large part of those 50 years. The fact is that the fine men and women who developed and sustained the large enterprise COBOL applications that run our governments, our banks, our insurance companies and other large commercial institutions have either retired in the last 10 years, or are about to retire in the next 10 years. Recently, in fact, a senior architect in a medium-size US Midwest insurance company explained to me that in the next 10 years, 50% of their development staff will be retiring.
Now, this wouldn’t be a big problem if we had enough young, eager, energetic ‘COBOL millennials’ lining up to fill the ranks of the aging ‘COBOL boomers.’ The reality is we don’t. The majority of colleges don’t teach COBOL - and if they did, the majority of students wouldn’t want to learn it. So, we have a problem. COBOL is still widely used, but here’s the news, it’s a language which is retiring. If we aren’t careful we’ll be faced with skill shortages and increasing resource costs impacting our ability to sustain these core applications into the future.
In reality, COBOL should have been retired some time ago, but three related factors have artificially preserved its life beyond the pool of skilled and experienced resources to maintain it:
First, COBOL is a relatively easy, relatively powerful programming language for developing large transaction processing applications. Because of this ‘fit for purpose,’ people have not been compelled to sit up and take notice of the fact that COBOL’s underlying technology is simply outdated.
Second, most organizations with large COBOL applications spent considerable amounts on those applications to solve the Y2K problem. Having made this significant investment, many organizations would rather continue to use COBOL code than face embarrassing questions about moving rapidly away from a technology they have invested in so heavily.
Third, the Y2K problem resulted in a significant increase in offshore outsourcing. This meant that offshore firms trained a new generation of COBOL programmers to address this need. Unfortunately, the cost of outsourced COBOL has risen with demand, while locally-based COBOL resources have continued to decline.
These three factors have contributed to prolonging the life of COBOL within organizations. But, we have now reached a time when as flexible as COBOL is, it doesn’t facilitate the type of digital transformation companies need to remain competitive. COBOL wasn’t designed to be a programming language that supports Object-Oriented, Agile, Cloud-centric development.
The recession of the 00’s shrank IT budgets, but now many CIOs are being given the chance to invest in digital transformation and are beginning to let go of their bias towards retaining their Y2K COBOL investments. In fact, a recent Gartner survey found that legacy application modernization was seen as a top 5 priority.
For those companies that have outsourced their COBOL development and maintenance, the need for digital transformation and modernization is superseding their desire to maintain current COBOL applications.
So, back to our partner in the US Midwest. What is he going to do? How did he evaluate his options and develop a strategy to deal with his COBOL problem? The good news is there are more viable options available now than ever before and there are proven processes for how he can get going. Inevitably, the best approach is to break your COBOL into manageable pieces and address each of them individually. In our next blog we’ll learn how our Midwest partner is getting started.
*2017 sees the 45th anniversary of COBOL becoming an ISO standard