ASNA White Papers
In-depth anaylsis, examination, and observations about ASNA products and the IBM i eco system.
Your business desperately needs your IBM i RPG applications to deliver your unique business value to your customers and business partners. RPG programming is a disappearing skill; by 2030 the typical RPG programmer will be 80 years old. Your RPG-dependent business is at risk with the disappearance of RPG programming talent.
There aren't younger RPG programmers in the pipeline and RPG programming is a disappearing skill
The IBM i runs many businesses today and its RPG applications perform unique and mission-critical processes. These businesses can't get along without them. Alas, the teams that built these applications are rapidly nearing retirement. There aren't younger RPG programmers in the pipeline. RPG programming is a disappearing skill. Despite IBM's best efforts to extend the life and capabilities of the IBM i platform, the fact remains that its RPG software needs RPG programmers to persist.
The decade between 2020 and 2030 is the decade of crisis for many IBM i shops. Can your business survive without its RPG programmers? The decade between 2020 and 2030 is the decade of crisis for many IBM i shops. Can your business survive without its RPG programmers?
This article references the System/38 (S/38) and the AS/400 as well as the IBM i. See this article if you’re not familiar with the lineage and naming of IBM’s various midrange platforms.
By 2030 RPG programmers will be very hard to find. RPG programming talent and the skills it takes to maintain and enhance RPG applications will be nearly obsolete in 2030. Don’t be mistaken: we’re not saying the IBM i will be obsolete in 2030. We’re saying that by 2030 programmers with RPG programming skills will be very hard to find. And without RPG programmers, businesses that depend on RPG applications will be in jeopardy. IBM i-based businesses that ignore or fail to understand the impact of losing their RPG programming teams put the business persistence in direct risk.
The risk is real
Consider the plight of New Jersey in its search for COBOL programmers. A 1600% increase in unemployment claims during the 2020 COVID-19 crisis overwhelmed their 40-year-old COBOL system. This caused New Jersey Governor Phil Murphy to put out an urgent plea for COBOL programmers. Oklahoma also had a similar issue.
During a press conference (saying “COBALT” but meaning “COBOL”) Governor Murphy said, “but given the legacy systems we should add a page [to the team’s planning] for COBALT (sic) computer skills, because that’s what we’re dealing with in these legacy [systems]…But literally, we have systems that are 40-plus years old. There’ll be lots of post mortems and one of them on our list will be how the heck did we get here when we literally needed COBALT programmers.” (See him say this in the last minute of this video.)
This business challenge is not COBOL-specific—RPG will suffer the fate. COBOL and RPG both appeared in their first rudimentary forms in 1959. In the coming years many IBM i shops will be without RPG programmers.
It’s not just New Jersey
New Jersey’s COBOL shortage is solid evidence that dependence on legacy languages is a critical issue. It’s not just New Jersey, either. This June 2019 United States Government Accountability Office report shows that of the federal government’s $90 billion budget, about 80% of it is aimed at keeping its legacy systems running. The report concludes that the government’s legacy systems need substantial upgrades and replacements and until they do that they risk higher costs, delays, and project failure. The report cited five examples of successful federal modernization initiatives that included transforming legacy code into a modern programming language and moving that transformed code to the cloud.
Don’t be in the same boat as New Jersey and the US Federal Government. The IBM i/RPG reckoning isn’t here yet, but it’s coming.
Delivering core business value
In the 80s and 90s business applications were very simple
Like the S/38, the AS/400 offered an operating system tightly integrated with its database and its computer languages. This made the AS/400 a good platform for creating business applications in the 1990s. Back then, business applications were relatively simple (especially when compared to today's networked applications that need to offer deep integration with customers and business partners). Without much formal training, budding RPG programmers created very effective RPG applications. In those days, security, cross-platform integration, a sophisticated user interface, and many features so common and necessary today simply weren't even on the nice-to-have list, let alone the need-to-have list.
The $230K top-end AS/400 in 1988 had 96MB of memory (that's not a typo—96 _megabytes_ of memory). An iPhone today has at least 1GB of memory. Your phone has enough memory to power ten AS/400s from 1988!
Those were simple days. The core demand back then was to automate a decades-old paper-driven system. The imagination, the computer power, and the tools didn’t exist to design and develop the kinds of applications we needed today. Who would have thought then that in 40 years we’d all have more powerful computers in our pockets and purses than we had in the office? In many cases, the applications RPG programmers built predated the AS/400 and were started on IBM’s System/38. Upon its introduction, the AS/400 was just more scalable and slightly-tweaked System/38. For most S/38 shops the upgrade path to the AS/400 was smooth and obvious. The old RPG needed only minor change to run just fine on the AS/400.
Your RPG applications ensure that your business can deliver its unique business value to your customers
In many shops, these young, and mostly self-taught, RPG programming teams built the core IT backbone of the business. 30 or 40 years later, these applications are still ensuring that your business is able to deliver its unique business value to its customers. These applications are critical and the business simply can’t get along without them—they are managing unique and business-specific complex processes and workflows. There may indeed be some generic aspects of this software that could be factored out. For example, some might include a general-purpose general ledger or accounts payable. However, even after factoring these more generic applications out, the remaining application is still huge by any measure and critical to business persistence.
Your RPG applications are critical and the business simply can’t get along without them managing your unique and business-specific complex processes and workflows.
76% of the respondents to the 2021 IBM i Marketplace Survey said that their IBM i business applications are “homegrown applications.” In nearly every case, these are the bedrock applications created by RPG teams all those years ago. Most probably had their genesis in solving a couple of very simple business challenges and over the years the application grew into this pervasive monolith that governs most, if not all, aspects of the business.
Good-bye, Boomer
By 2030 nearly all available RPG talent will have retired. Let that sink in.
Baby Boomer birth years are generally considered to have been from 1946 to 1964. Many, if not most, RPG programmers are baby boomers. At the end of the new decade (2030) baby boomers will be from 66 to 84 years old! By the end of decade, even the youngest boomer will be 66 years old. By 2030 nearly all available RPG talent will have retired. The RPG talent still available in 2030 will be very hard to find and expensive when you do find it.
Most RPG programmers will be retired by 2030 The aging RPG programmer chart
The IBM i was introduced in 1988. There were probably some 20 year-olds (or so) new to RPG programming in 1998 (when the AS/400 was introduced) so not all RPG programmers are boomers. However, even an 18-year-old who came on board in 1988 will be 60 in 2030. Let’s generalize a little and assume that today’s typical IBM i RPG programmer was born in 1950. That makes that typical RPG programmer 80 years old in 2030. Many boomers today are working beyond the traditional US retirement age of 65, but very few are working past 80. By 2030 nearly all available RPG talent will have retired. And for any IBM i-centric business deeply dependent on its RPG applications that is a huge problem. Offshore outsourcing may offer some respite to the RPG programmer shortage. However, not only does using offshore outsourcing dramatically change your RPG maintenance/enhancement workflow it imposes substantially communication challenges, cultural considerations, and a general imposition on your RPG programming comfort zone.
The typical RPG programmer will be 80 years old in 2030
That’s bad news but it gets worse. Not are RPG programmers on the cusp of retirement, young programmers haven’t, and won’t, enter the RPG pipeline. Programming/IT college students don’t encounter either the IBM i or RPG. The IBM i and its RPG programming language simply aren’t on any young programmer’s radar today.
The reality is that most IBM i shops with an RPG dependence have a crisis coming very soon. Offshore outsourcing may offer some respite to the RPG programmer shortage. However, not only does using offshore outsourcing dramatically change your RPG maintenance/enhancement workflow it imposes substantially communication challenges, cultural considerations, and a general imposition on your RPG programming comfort zone.