ASNA White Papers
In-depth anaylsis, examination, and observations about ASNA products and the IBM i eco system.
This article considers the perils and pitfalls of attempting to rewrite your RPG application from scratch. You need to carefully consider the big rewrite option from every angle-it is destined to be the worst step you can take.
Rewriting a large, mission-critical enterprise application is a demanding, challenging task with a high likelihood of failure
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 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.
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.
Reasons to rewrite the application are almost always focused on the
> programmer domain, not the business domain
Think about the list above of reasons for moment or two. Reasons to rewrite the application are almost always focused on the programmer domain, not 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.
Asking your programmers if they should rewrite your software is like asking your waiter if the special of the day is any good. The answer is predictable and lacks objectivity.
Considerations for rewriting your software shouldn’t be programmer-driven, they should be business-driven. The questions that need 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?
How will we know the new application is 100% 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?
A good global assessment provides you with the single source of truth you> need to make sound decisions about your application
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 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? This needs to be created in detail, with user stories and a clear picture of the data flows and processes.
What is the timeline for rewriting the software?
What resources do you need (ie, programmers, tools, servers, etc)?
RPG programs don’t live in a vacuum. How, and with what, will you replace the supplemental parts of your system (ie, EDI, telephony, job scheduling, et al).
Estimating the time a rewrite takes
In almost every case, the timeline for delivering an enterprise application rewrite is woefully out of touch with reality.
It’s very likely, almost assured, that the team that would rewrite your RPG application has 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, the timeline for delivering an enterprise application rewrite is woefully out of touch with reality.
Under the best of circumstances rewriting your RPG application is a multi-year endeavor
The RPG system to be replaced has hundreds of thousands, or even millions, of lines of code. How many programmer years does that represent? Let's assume your shop has four RPG programmers (According to the 2020 IBM i Marketplace Survey 47% of IBM i shops have 3-10 RPG programmers). If your team worked actively on your RPG application for ten years, that application represents 40 programmer years of work. Under the best of circumstances rewriting your RPG application is a multi-year endeavor.
Don’t let anyone tell you otherwise!
The Mythical Man Month is a highly-respected book that every technical manager should read. Although the book is many years old, its messages and wisdom about project management and herding programming teams remains on-target and well-aimed. It is highly-recommended reading for critical decision makers.
What about your existing 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?
The IBM i database is branded as a DB2 database, but it isn't
> plug-and-play with DB2 on other platforms
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 your existing database needs to be refactored and cleansed before any new software can be written. This alone is enormously challenging and absolutely cannot be overlooked. 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 will undergo typical maintenance and changes (ie, keeping up with changing regulations).
Identifying what can be rewritten
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 solutions 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.
Look for components with narrow scope and intent that can be easily isolated and replaced with off-the-shelf software without sacrificing business> functionality
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 a rewrite or 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.
These articles provide outside perspectives on the perils of The Big Rewrite: