Closing the COBOL Programming Skills Gap

The backbone of today’s electronic commerce is COBOL on an IBM Z computing platform. There are 240 billion lines of COBOL in operation, and another 5 billion new lines are added each year. $3 trillion of commercial transactions are processed by COBOL applications each day. COBOL is what business runs on.

Some reports indicate that the 240 billion lines of COBOL code are the second most valuable asset in America, right behind oil. How did COBOL weather 60 years of technological evolution? Because there are classes of information processing that are ideally suited for COBOL on a mainframe. Back-end, high-volume transaction processing must work correctly, securely and fast. If you must process several million transactions in the six-hour overnight batch window, IBM Z COBOL is what you use.

But the community of COBOL programmers is shrinking faster than the open positions they create can be filled. The average age of a COBOL programmer is 58, and roughly 10% are retiring each year. It is estimated that there will be 84,000 unfilled mainframe positions by 2020.

Very few schools still teach programming and even fewer teach COBOL, although there are boot camps teaching Java, Python and other languages. The Enterprise Computing Community has been active in reviving and supporting efforts to educate people in IBM Z technologies and languages.

If we do not replace, or even expand the shrinking force of COBOL programmers, we will be left facing a tragic problem.

Why Is This a Problem?

The foundation of American and worldwide business depends on COBOL applications running the billions of daily back-office transactions. Banks, insurance companies, airlines, ERP systems, stock exchanges, fulfillment centers and more are all required to process large numbers of transactions in a bounded amount of time. The applications they count on to accomplish this vital task run COBOL on IBM Z.

The industry has already tried several strategies to mitigate the COBOL skills shortage:

1. Rewrite the existing COBOL mainframe applications in more modern languages like Java or Python and move it to the cloud.

There are several issues with this strategy. This approach has at best a spotty track record. Re-implementing an application in another language requires extracting the business rules embedded in the COBOL, from a codebase that has evolved over many years of modification and enhancement, and which unfortunately is not very well documented. Retiring programmers take with them all the institutional knowledge and subject matter expertise they gained over decades.

These applications have little or no documentation and what may exist, is arguably out of date. From a project management perspective, the challenge of accurately re-implementing the business rules in a new language can be insurmountable. At best, they are hard to quantify or predict, and tend to contribute to cost and budget overruns, or project failures. The technology risk is often too significant for an organization to absorb, or organizations cannot mitigate the associated continuity of business risk. Re-writing foundation COBOL applications could be a career-ending decision because of the high-risk profile of such an undertaking. Justifying the outlay of millions of dollars to re-write a perfectly good application in another language can be done but requires the right use case(s) and skilled advocates.

Secondly, there is no guarantee that Java or Python will not suffer the same skills shortage some years from now as newer languages continue to join the fray.

2. Do more with less.

Change the way we maintain existing COBOL IBM Z applications, so that fewer people can do more work by being more efficient and effective.

This could be a possible stop-gap measure but unfortunately, in many instances, the existing codebase isn’t well documented, has many complex logic structures that do not lend themselves to automation and, based on anecdotal software engineering evaluations are in many cases, not well structured nor do they meet acceptable software metric standards.

3. Outsource the COBOL development and enhancement.

This has been tried and has proven to be less effective and undoubtedly less efficient than anticipated for a few reasons:

• There is a turnover rate of 20% or more among offshore COBOL outsourcers; resulting in a lack of continuity and knowledge.
• The people who become COBOL programmers don’t have the same expertise as front-end developers. COBOL developers are trained in structured design and coding. In addition, they are used to working on large systems with millions of lines of compiled code. COBOL maintenance and programming are migrating to new locations: Poland, the Baltic countries, Russia, etc., which don’t have the cultural familiarity with the business rules to be fully capable.

If the continued use of COBOL and mainframes is, as we believe, inevitable, or at least until someone produces an alternative that is as efficient and effective, the most appropriate solution is to train a new generation of COBOL programmers and help them understand these three fundamental skills:

1. IBM Z operations—how to write, test and operate applications and data structures in an IBM Z environment
2. Programming—the understanding and ability to design programs and understand the fundamental skills needed to be a programmer – this is a topic unto itself
3. COBOL—the structures and nuances of the COBOL language

How Did We Get Here?

One cause of our current state is that as an industry, IT is focused on advancement. We allow stable, mature technologies to simply linger off the radar while newer technologies fill the gap.

Writing COBOL programs is not considered as glamorous as creating the next big website or application. Computer science schools have stopped teaching COBOL and, in many cases, stopped teaching programming altogether. Programming is now often the domain of community colleges and fee-based boot camps.

For decades there was a powerful movement to outsource applications (COBOL on IBM Z) overseas; to India, Poland and other locations. Two issues have made this alternative problematic.

1. Today’s heightened international tensions and dependence on overseas programming support results in higher risk. This leads to cutting the offshore fiber optic cables, insertion of malicious code and reduction of programming quality and experience.
2. There’s a shrinking domestic population of skilled and experienced COBOL programmers. We aren’t training a sufficient number of people to replace our existing cadre of COBOL programmers. At some point soon this will result in critical applications not being maintained or enhanced, because we will not have enough people to do it.

Mitigating the Problem

We must make the an effort to train people to be COBOL programmers. Not computer scientists—but people who have been displaced through automation or reductions in force, returning veterans or those who have degrees but cannot find jobs. More schools and boot camps need to teach fundamental COBOL and IBM Z programming. We also must enlighten others to the more “glamorous” aspects of COBOL. For example, COBOL represents an excellent well-paying career-path.

There are both short-term and long-term actions that we can do now to fill the COBOL programming skills gap:

1. Increase the number of schools, colleges and universities that teach programming and COBOL
2. Increase the number of boot camps and private trade schools training facilities
3. Support the IBM Z Academic Initiative for IBM Z and COBOL education and training
4. Give COBOL its rightful place in the value matrix of your IT organizations, so that it gets the attention needed to guarantee its faithful service for years to come
5. Create a succession plan for those who maintain and enhance our foundational COBOL applications, and be sure it addresses the knowledge transfer needed for a smooth transition of all resources
6. Have enough staff to overlap in time and provide apprenticeship programs to ensure that whoever is implementing a critical fix in production at 2:00 a.m. is prepared
7. Upgrade testing and security standards and procedures to be in line with today’s best practices
8. Document existing applications and data structures. Much of the COBOL documentation is outdated, and the work gets done because the people who maintain the code have years of folklore knowledge and know the code. However, what happens when people with oral traditions and folklore retire?  We need to make sure that that knowledge is captured and maintained. Several excellent tools can dynamically capture the documentation and business rules of existing code. These tools also provide information about how well the code meets software engineering standards and metrics.

Our COBOL Training Curriculum

To contribute to solving this problem, Back In Time Solutions developed a COBOL training curriculum that we believe is unique in scope, breadth and pedagogical approach. Our curriculum is designed to train new people in the maintenance, enhancement and when necessary, migration of existing COBOL programs to more modern platforms. We intend to not only teach students how to write programs in COBOL but also how to do it well and do it correctly.

We combined a robust COBOL curriculum with a set of companion training tracks in soft skills, software engineering principles, and problem identification, analysis, and debugging. There will also be an optional two-week program in customer-specific tools, methods and techniques. Students emerge from our program, with training in COBOL, soft skills, and software engineering—which significantly reduces the time required for them to be productive members of the customers’ programming team.

Our pedagogical model is based on frequent and in-depth interaction with the client during our proposal process and determination of what skills and capabilities best fit their specific COBOL ecosystem. Our use of chief programming teams, ensures increased and earlier productivity by teaming our graduates with experienced chief programmers who have knowledge of the customer’s ecosystem, thus reducing the mean time to productivity (MTTP). The chief programmer team approach mitigates the impact of employee turnover, and the collective knowledge of the team compensates for the loss of any single member.

Figure 1 illustrates our multi-discipline, multi-dimensional approach to teaching COBOL skills and competencies.

Figure 1

We divided our discussion of the curriculum into four parts:

1. COBOL—how we will teach the necessary COBOL skills? For pedagogical reasons, we selected to use a standard COBOL textbook supplemented with instructor lead lectures, exercise and when appropriate, customized materials.
2. Soft skills—the competency and expertise needed to be successful in a business environment
3. Software engineering—an in-depth discussion of the principles of software engineering that a programmer needs to know including problem identification, analysis and correction, along with how to identify and fix bugs
4. Optional customer-centric training—the knowledge of the customer’s specific ecosystem. This section of the training program will be customized for each customer and will be developed by the chief programmer in conjunction with the customer.

The COBOL training programming curriculum is scheduled to run for 12 weeks with the ability to add an optional two-week customer-specific program.

The individual instructors for each course have the freedom to determine what they do in the allocated time slots. We have, however, developed a set of weekly lesson plans at the day/objective level. Also, we developed a recommended set of texts and teaching materials. Providing this level of instructor discretion is an essential part of the learning process.

See Figure 2 for an overview of the COBOL, soft skills and software engineering tracks.

Week	COBOL	Soft Skills	Software Engineering
One	Introduction to COBOL Programming	Professionalism and Business Etiquette	How a Computers Works
Two	How to Write a Program—Structured Programming	Rules and Regulations of the Workplace	Overview of Mainframe Components and Operations
Three	COBOL Features	Notational and Diagramming Techniques	Flow of Control
Four	Working With Fields	Business Communications: Part 1 (Listening, Reading and Writing)	Data Structures
Five	Working With Dates, Characters Tables	Business Communications: Part 2  (Writing Technical and Non-Technical Reports)	Design Paradigms
Six	Using Copy Members	Business Communications: Part 3 (Reading and Writing Requirements and Documents)	Quality Engineering and Testing
Seven	Working With Files	Business Communications: Part 4  (Public Presentations—How to Prepare and Give Them)	Project Management
Eight	Working with: Indexed files Relative files Sort and merge	Teamwork (Part 1)	Organizational Structures of Design and Programming Teams
Nine	Introduction to IBM Main Frames	Teamwork (Part 2)	Security and Privacy
Ten	Access Methods	Practical Problem Solving in the Business Environment	Alternative Technologies and Paradigms
Eleven	Introduction to Db2 and DBMSs	Meetings 101 and Meeting Behavior	SDLC
Twelve	Introduction to Maintenance Programming	Essay and Final Presentation	How to Read Static and Automated Program Documentation

Figure 2

We created an integrated training program that incorporates the best educational and pedagogical concepts. This is competency-based, interactive learning tailored to accommodate multiple learning modalities with short interval evaluation and feedback. Upon completing the training program, the student, their team and chief programmer will be ready to help close the impending COBOL skills gap.

Moving Forward

By implementing the short- and long-term strategies detailed earlier, and supporting programs like our proposed COBOL curriculum, we can find a way to close the growing COBOL programming skills gap. COBOL is no doubt key for the IBM Z community, so it’s crucial for us to make this a priority.

---