Rewriting IBM i RPG Software Is Almost Always A Bad Idea
October 13, 2021 Roger Pence
There are perils and pitfalls in attempting to rewrite your IBM i-AS/400 RPG applications. While there are some cases where such an attempt may be a good idea, you need to consider the big rewrite option carefully from every angle. It is often the worst step you can take.
As you start to realize that your IBM i RPG software, at least in its current form, is nearing the end of its useful life, rewriting your RPG application is an obvious alternative. We implore you to give this option very serious consideration before you jump into it. Rewriting a large, mission-critical enterprise application is a demanding, challenging task with a high likelihood of failure.
At ASNA, we’ve discussed persisting IBM i RPG applications with many customers. When discussing rewriting the application, the most common reasons we hear for wanting to rewrite the organization’s software are:
- Our current code is awful.
- We can do such a better job this time.
- We used the wrong programming language the first time.
- We can make it faster and add more features.
- We didn’t understand what we needed then and we do now.
What do these reasons all have in common? None of them convey why rewriting the application is good for the business. Reasons to rewrite the application should not focus on the programmer domain; they should focus on the business domain. Programmers love to write new software, use new tools, and explore unchartered territories. Programmers can tell you many ways rewriting the software will benefit them – however they aren’t so good at telling you how rewriting the software will benefit the business.
Reasons for rewriting your RPG system of record should be business-driven. The questions that need to be answered in the planning stages aren’t what new programming frameworks to use – rather they should address issues such as:
- How quickly can the application generate an ROI for us? And how will we measure that ROI?
- How will we know the new application is 100 percent correct?
- How can we best budget resources and create a realistic timeline?
- Will the new version persist our ability to keep our customers and business partners happy?
Thinking deeply about such issues starts to reveal your need to do a comprehensive global assessment on your existing application before you make any decisions about it. It is very important to make decisions based on exactly what you have, not what you have according to handed-down kindred knowledge. A good global assessment provides you with the single source of truth you need to make sound decisions about your application.
A Rewrite Is More Than Writing Code
The task of rewriting software, especially decades-old software without any written documentation, isn’t just about writing code. In fact, writing code is the easy part. But before code is written, you need to determine things like:
- How are you going to test your new software? How will you know that it works?
- What are the software’s requirements? You need detailed requirements with user stories and a clear picture of the data flows and processes.
- What is the realistic timeline for rewriting the software?
- What resources do you need (such as programmers, tools, servers, and so on)?
- RPG programs don’t live in a vacuum. How, and with what, will you replace the supplemental parts of your system (for example, EDI, telephony, job scheduling, and the list goes on).
It’s very likely that the team that wants to rewrite your RPG application has very limited knowledge of that application. It’s critical that this team fully understand the scope and complexity of the original application. Even armed with such knowledge, it’s very tough to create, and even tougher to adhere to, a delivery schedule. In most cases, and with the best intentions, timelines for delivering an enterprise application rewrite are woefully out of touch with reality.
Your RPG system of record has hundreds of thousands, or even millions, of lines of code. How many programmer years does it represent to rewrite it? Let’s assume your shop has four RPG programmers (According to the 2021 IBM i Marketplace Survey 69 percent of IBM i shops have one to ten RPG programmers). If your team worked actively on your RPG application for ten years, that application represents 40 programmer years of work (Figure 1). Under the best of circumstances, rewriting your RPG application is a multi-year endeavor.
Don’t let anyone tell you otherwise!
The Optimistic Rewrite
What About Your Database?
Another very important question to get answered before you green-light a large rewrite project is: How will you migrate and refactor your database and ensure its veracity?
Before any programmer writes the first line of code, your database will have to find a new home. Beyond being very large the IBM i database is a database like no other. The IBM i database has idioms and constraints not found in virtually any other database. Even though the IBM i database is branded as a DB2 database, the IBM i version of DB2 isn’t plug-and-play with DB2 on other platforms.
Moving your IBM i database for a new application isn’t just a matter of copying data from one database to another. It’s almost a certainty that you’ll need to refactor and thoroughly cleanse your database before programmers write any new software. This database work alone is enormously challenging. The challenge of moving your database gets even more imposing when you consider that it is a moving target. During the many months of writing new software your database needs undergo typical maintenance and changes (that is, keeping up with changing business regulations).
Identifying What To Rewrite
Identifying the components that can be rewritten doesn’t directly solve the challenge of what to do about your core RPG application. However, replacing anything you can identify as not providing a core facility to persisting your unique business value helps make the challenge of replacing your RPG system easier.
An IBM i RPG application is very often a monolithic, do-everything application. Most of these apps grew up in the very early years of business computing — well before the days of a plethora of third-party packages or today’s cloud-based solution platforms. Because most AS/400 shops had RPG programmers in the early days, it was natural for those programmers to write solutions that weren’t just business-specific, but also write those that did more general-purpose work such as general ledger or accounts payable.
As you ponder replacing your RPG system of record, any component that you identify as not being a core part of your RPG application may be a candidate for replacing with a third-party solution (this may include components such as general ledger or accounts receivable). In this case, the scope is narrow and the intent of the component is easily isolated and defined.
An eternal struggle exists identifying what is an independent component in enterprise RPG applications: most components in an older RPG system have levels of vertical interoperability with other components. It’s very common for a mostly generic component to reach across and directly affect the inventory component. When you do find this “fence-jumping,” the cost of decoupling and reengineering alternative integration with third-party components determines if these components can be replaced separately or should be considered a core part of your RPG application.
A Tough Call
Rewriting enterprise software is a challenging, long-term endeavor. You need to investigate this alternative from every angle and have very realistic expectations. While a big rewrite isn’t guaranteed to fail, the odds are it won’t succeed. It will not only waste money, but more importantly, time.
Planning for business persistence with an aging RPG application and a fading pool of RPG programmers is a challenging task. At ASNA we think the key to resolving your challenge is your RPG source code. Our application migration suites can transform your RPG source into a modern, effective C# application that a new generation of C# programmers can maintain and enhance. To read more about our approach to your RPG challenge, please visit The Decade of Crisis for the IBM i and RPG or ASNA.com.
Roger Pence has been a product specialist with ASNA for 20 years. He has been involved with the IBM i midrange community for many years. He has written many articles about the IBM i and RPG.
This content is sponsored by ASNA.
RELATED STORIES
These articles provide other perspectives on the perils of The Big Rewrite:
Why You Should Almost Never Rewrite Your Software
The Myth of the Software Rewrite
A Code Rewrite Cautionary Tale
LInes of Code is a terrible metric. It’s like measuring the productivity of an aerospace engineer by the weight of the plane.
Really? The previous day an article about how ibmi is capable when complemented with modernization tools and the next an article about suggesting a C# rewrite? Are you kidding right?
“Rewriting IBM i RPG Software Is Almost Always A Bad Idea”. This has been proven many times. As a matter of fact, IBM i shops fail at far simpler tasks. I’ve seen several organizations fail repeatedly at simply attempting to convert from RPG native IO to SQL. *rontier *ommunications made three attempts in three years with a project team of about thirty developers. Thirty times 2000 hours times $100/hr is $6 million which used to be real money.
I have transferred data from IBM systems to SQL Server many times. Then imported into new software, not a re-write. There is no single simple answer on this. Every situation is different.