Is 2030 The New Y2K?

September 30, 2020 Michael Killian

In the world of IBM i transformation, time may not be your friend. RPG resource availability is at an all-time low, and forecasts do not look promising for any resurgence. That fact, combined with the reality that a full-blown transformation initiative can take several years on average, simply means that putting off aggressive digital transformation activity is no longer an option for most organizations.

Without People, Technology Doesn’t Matter!

There’s a great book called The Technology Fallacy: How People Are The Real Key To Digital Transformation, which anyone considering a transformation initiative should consider reading. The book doesn’t focus on technology directly in regard to transformation, rather it speaks to the organizational change required in order to harness the power of technology. Stated simply, without people, technology doesn’t matter. The book addresses a key concept of digital maturity that organizations need to reach in order to fully leverage new technologies. This is such an important concept for IBM i organizations.

Whereas most might argue that the programmers that make up IBM i shops are typically mature from an age perspective, the real focus of digital maturity is how those people within the shop stay abreast of and wholly utilize the latest technologies. The unfortunate truth is that because the core applications RPG programmers have written over the decades require so much maintenance (up to 72 percent of development budgets are for maintenance of applications according to Forrester), it becomes easy to see why staying up with, let alone using, the latest technologies is challenging for many IBM i shops.

So, Why Is 2030 My New Deadline?

First, let’s look at this topic of ‘people’ from a different angle. The biggest risk-reducer for most transformation initiatives are the people involved. Certainly, in a world of code transformation, RPG programmers probably know the business as well, if not better, than anyone. If we all agree that having someone that understands historical context is so important for successful transformation, then it becomes evident that the RPG programmer’s background in a transformation project is priceless. They know why certain decisions were made 20 years ago that led the organization down a specific path. . . they know the competitors in the market. . . they know the “secret sauce” that differentiates the organization. . . and they understand how each individual department works and interacts with others, including the customer. Those programmers used that in-depth knowledge to write the applications that brought the organization to where it is today. But here’s that key take-away: There is a time-bomb ticking away!

Pew Research states that the majority of legacy code (that is, RPG code) was written by baby-boomers, and Pew’s research along with U.S. Census statistics state that all baby-boomers will be at or beyond retirement by the year 2030. If you utilize basic mathematics and start with the fact that 2030 is only 10 years away, and then you start subtracting the time needed for transformation steps (typical year needed for assessments, roadmaps, executive buy-in, budget – then the transformation itself – taking one to five years on average – and contingency plans for bumps along the road like Covid-19), it becomes clear that organizations need to move now in order to extract that tribal knowledge locked-up in the heads of those RPG programmers before those RPG programmers are no longer available to share that knowledge (and by not available, I’m hopeful that they are relaxing on a beach and enjoying the fruits of their labors during their retirement years).

Apprenticeships Open Doors To A Better Future

So, acknowledging that people are key to a transformation initiative and recognizing the immense value that the RPG programmers bring to your business, how should you move forward in the most effective way? I’ve been a huge advocate of apprenticeships for years, and I don’t think there has ever been a time where apprenticeships make more sense than now. In fact, Forbes recently stated that “companies that invest in apprenticeship programs stand to reap the immense advantage of a carefully trained, highly skilled workforce that can deliver in ever-evolving, ever-demanding business environments.” If you think about it, reaping the immense advantage referred to by Forbes is probably one of the key drivers for your digital transformation initiative anyway, so how do you go about creating an apprentice program?

First, be absolutely clear with your existing staff in advance of making any changes. Transparent and bi-directional communications go a long way toward overall project and work satisfaction for all involved. If you start moving forward with plans without talking with your team first, you may not receive the type of response you were hoping. In fact, instead of support, you may actually have push-back…and then your initiative has hit an obstacle before even starting. Simply meet with your existing team to let them know: how valuable they are, that an initiative is underway to ensure long-term business continuity and growth, that their participation is vital to the success, and that you’d love them to be an integral part of the contributing team up to (and perhaps beyond) retirement. Ask for their input on how they think they can best help in this new apprenticeship model and work their idea(s) into the plan.
Make the investment in modern language developers today. If you haven’t already determined which target language makes sense for your organization, be sure to read my previous article on choosing the right target language here. And after you have completed your due diligence on the target language, simply begin your hiring process.
Start cross-training your RPG developers on the new target language. Regarding this educational point, the ease in which newer and older programmers can adopt a new language should be an important part of your target language decision. This allows those RPG developers that are perhaps not interested in retirement to continue contributing in the new environment.
Perform your normal onboarding processes with the new hires so that they have a high-level understanding of the company, processes, culture, values, and procedures. And be sure to set the expectation that they’ll be partnered with someone for the next year or more that will mentor them.
And lastly, introduce the RPG programmer(s) to the new developer(s), provide them only high-level guidance, and watch the passion of technology begin melding when the knowledge transfer happens and both programmers begin to appreciate the unique talent that the other has and how by combining forces that they jointly create a strong foundation for tomorrow.

Don’t Forget About Partnering With Experts

What if an apprenticeship is not an option? Or what if you need to augment that apprenticeship model? Remember that partners are people too and are therefore extremely important to the transformation plan! As you choose a partner, it is best to proceed with a partner that can help you from an automation perspective, but that also has expertise in transformation and modernization, and has staffing available to assist along the journey.

This could be providing staff augmentation to supplement the RPG developers that were previously maintaining the code and who have subsequently moved on to be part of the transformation project.
It could be (and probably should be) the partner that actually provides the transformation of the code, user interface, and/or database as the knowledge needed for the actual migration process requires expertise. It typically doesn’t make sense for organizations to educate their own team members for what would probably be a one-time transformation event over the upcoming decades.
It could be for short-term post-migration support for the new technology if needed for a period of time.
And lastly, it could be a long-term outsourcing engagement, especially if one of your reasons for transformation was to get the company to a point that allowed them to focus on their core business instead of the technology required to run the core business.

Time Is Of The Essence!

Regardless of how you proceed with your resourcing plan for pre-migration, the migration itself, and post-migration. . . the key to remember is to just start. There are so many steps that need to be taken between now and 2030, including but not limited to due-diligence of options, vetting, road-mapping, documenting, approving, executing on, delivering, testing, moving into production, and finally maintaining/enhancing those transformed programs.

If you’re ready to start, but not sure how, simply set-up a time to meet and I’ll be glad to offer my advice. We would be honored if @ProfoundLogic can assist with your transformation initiatives, but we’d be happy to simply have a conversation if that is what you prefer.

And, if you haven’t had the opportunity to read the other articles already published in this series on the Top Things to Consider When Modernizing and Transforming IBM i Legacy IT Environments, I hope that you take time to do so. . . and please be sure to follow me so that you are notified of future articles on this topic, which are scheduled for every two to three weeks. In the interim, stay well and don’t wait until it’s too late to start your transformation journey!

This content is sponsored by Profound Logic.

Michael Killian is vice president of strategic accounts at Profound Logic.

3 thoughts on “Is 2030 The New Y2K?”

carole says:

September 30, 2020 at 7:29 am

Here I thought 2039 was the new Y2K!

- Ralph Daugherty says:
  
  October 5, 2020 at 2:34 pm
  
  Close, but 2038 is the Unix timestamp rollover.
  
Ralph Daugherty says:

October 5, 2020 at 2:55 pm

quote:” The unfortunate truth is that because the core applications RPG programmers have written over the decades require so much maintenance (up to 72 percent of development budgets are for maintenance of applications according to Forrester), it becomes easy to see why staying up with, let alone using, the latest technologies is challenging for many IBM i shops.”

This really ticks me off. I’ve been doing RPG since 1989, for F500’s and for vendors, and PC programming with startups for 8 years before that, so I’ve done plenty of programming from scratch and plenty of working on existing code, sometimes same day.

This 72% figure is the worst stat that I’ve seen from marketing people in some time, and that is a very high bar to cross. “Maintenance” is modifying existing programs. Well how often is a new program written? Do you think we would just throw away existing programs so we can say we’re not doing maintenance programming? The larger a code base, the more time spent in the code base rather than adding new programs to the code base. Because each of those new programs now becomes part of the code base, and they will be modified.

The other aspect of this is that the term “maintenance” is used with a negative connotation of something unpleasant that neither the company or the programmer want to do. Far from it. In fact “maintenance” is adding new functionality, let’s say 72% of the time, so 72% of 72% is new functionality added to existing programs in code base.

Bottom line, businesses know what capabilities are being added and they have no idea and shouldn’t need to think about what portion of that new capability was in a newly created program and what portion was added to existing programs. Sometimes we RPG programmers do very large scale new subsystems with almost entirely new programs and little modification to existing code base, but once completed, any modifications to that are now “maintenance”. It’s only a matter of terminology and doesn’t matter to anyone except someone trying to denigrate our work for their own purposes.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search