Set up your RPG modernization project for success by first deciding if the app is worth modernizing, then take it slow, set realistic goals, and let go of old programming habits

Editor’s Note: This article is excerpted from chapter 12 of Evolve Your RPG Coding: Move from OPM to ILE ... and Beyond, by Rafael Victória-Pereira.

Are you considering modernizing your tried-and-true RPG applications? Before you get started, consider these three tips to help you give your project better odds of success.

Step 1: Answer One Important Question

You probably never thought of it this way, but before investing a cent in a modernization initiative, you should take a good, hard look at your application and ask this question: Is my application worth modernizing?

You need to know if your application is of real value to the business. Consider whether it provides significant value, considering these elements:

•             The business success globally of companies using the platform

•             The competitive edge encapsulated in the legacy application

•             The total cost of ownership being delivered to clients, suppliers, and partners

•             The cost and risk of the viable alternatives

If not, well … it can be a hard decision, especially because of all the years of hard work you put into it, but it does not make sense to modernize the application. It then becomes a simple choice of retire or redevelop.

If your applications provide a significant value that you’ve determined needs to be retained, you can start by modernizing those applications to a “modern” database environment such as DB2 SQL. This enables you to take advantage of the most recent database features, as I mentioned earlier. Before you begin, however, there are a few more questions related to critical operational and strategic constraints that you need to answer:

• Does the application provide a competitive advantage? For instance, a unique order entry process, special stock allocation, and stock management algorithms that are in total sync with the business and are hard to re-code in a different platform comprise a constraint of paramount importance.
• Can your current business processes be improved? Maybe, just maybe, the problem is not in the application, but in the business processes themselves.
• Will the system allow this improvement? It’s simply not possible to get a jet engine under the hood of a Ford Model T and expect it to run. You need the right tools, in this case a reasonably up-to-date system, to support your modernization initiatives.
• What is inhibiting service delivery models for clients, suppliers, and partners? Try to identify the part or parts of the application environment as a whole, not just the IBM i application, that are causing the bottleneck in service delivery. You might need to redesign a business process or upgrade another hardware component instead of changing your application.
• What is the functional fit of your current application? As a rule of thumb, off-the-shelf applications will deliver between 60 percent and 75 percent of the required functionality. With years of customization and constant maintenance, it’s possible that your application is somewhere around 90 percent or higher. You’ll need the help of the application’s users to assess the functional fit. Keep in mind that you need to perform this assessment in a period in which the application has been running smoothly for a while. Otherwise, users will complain about performance and availability and won’t be able to provide an unbiased assessment.
• Do the constraints you experience stem from a lack of functionality or service delivery? This is also something you can include in the user assessment, but you need to help users distinguish between the two concepts.
• Can you document the cost structure to deliver the applications? This is a big deal because managers are fond of cost savings. If you can convince them that an investment in a modernization initiative can save the company a considerable amount in the coming years, it might soften the blow they’ll feel when you show them the initial cost estimates for the modernization initiative.

If you can get answers to all these questions, and they all point in the “it’s not worth it” direction, then you know what you should do. However, in most cases, you’ll see that it’s worthwhile modernizing your applications. Don’t modernize for the sake of modernizing, however! Get users and, most importantly, management, on board with you, and chart your course carefully before setting sail on your modernization adventure.

Step 2: Avoid the Pains of Modernization

Modernization is usually a long and hard process. Everyone gets excited about the gains of modernization and often ignore the pains. Here are some tips to avoid the most common modernization pains, starting with the most obvious:

• Drop old habits. Modernizing implies doing new things, in a new way. The problem is that we’re used to staying in our comfort zone. A modernization process really takes us out of it; you’ll need to learn how to work with new tools, look at problems in a different perspective and, most importantly, drop those old habits that you’ve picked up over the years.
• Think big, start small. It’s not a good idea to try to modernize an entire application at once. This common mistake can have a dire financial impact on a company. The way to go with your modernization process is to think big but start small. Set your general modernization goals for the whole application, but don’t even try to plan the modernization of the complete thing—you’ll just get frustrated and regret ever starting the process. Instead, the sensible approach is to select a module or part of the application and analyze it carefully, with the help of the application’s users.
• PoC it. A proof of concept (PoC), is a critical, and often-overlooked, part of a modernization process. By starting small and creating a PoC, you’ll be able to evaluate different options, technologies, and strategies. You’ll be able to realize what you did wrong and correct it, without incurring huge costs. You’ll also gain invaluable experience for the “real” process.
• Get professional help. A modernization process, even a small one, is filled with new things. It’s easy to get overwhelmed by the numerous small details you’ll need to pay attention to. There’s no shame in bringing in a modernization consultant to help you understand your options and how to plan your project. You’ll also need training in the new tools you’ll be using throughout the process. It’s not enough to go online, read a couple of tutorials, and assume that you’re ready to use the tool. You need to take time to learn and practice before getting your hands dirty with the real thing. Of course, nothing replaces the actual work, but in this case, you’ll have so many different things to worry about that you’ll need to prepare appropriately.
• Set realistic goals. You’ll need to discuss the modernization process goals with users and top management. Once you show them the many modernization tools available, they’ll want everything, or at least more than is reasonable. Naturally, you’ll also have to curb your own enthusiasm for all the cool things you can do with those shiny new toys.
• Design and implement a communication plan. This process is usually a long one, and it’s not easy to keep everyone motivated and focused on the ultimate goal. Keeping those not directly involved in the process “in the dark” leads to rumors, resentments, and a bad work environment in general. Designing and implementing a communication plan is every bit as important as the actual implementation of the modernization plan. You might want to prepare different announcements for participants in the process, as they will need to know more details and will have more questions. This group of people needs special attention because they are the backbone of the modernization process, so it’s critical to keep them informed and motivated.

Step 3: Set Your Modernization Goals

There are three modernization areas:

• Code modernization
• User interface modernization
• Database modernization

A modernization process can include any combination of work in these three areas, which means that you need to plan the process carefully. The first step is analyzing the current application in an unbiased assessment, with the help of its users and your top management. Depending on where the real problems are, you can have different approaches to the modernization goals:

• Performance issues can be tackled with either code modernization, database modernization, or even both, depending of the situation.
• Lack-of-agility issues are usually caused by an inadequate application and/or database design, so the same approach as in the previous point applies.
• New business demands, such as ensuring all or part of the application is available online with a Web or mobile front end, may be addressed with a mix of UI and code modernization.

Keep in mind that these are just examples, and each modernization process is unique. Bringing in external expertise at this point is a great idea. An experienced modernization consultant will be able to help you discover quick wins that can provide some traction to the process and share invaluable insights regarding the challenges ahead. Always remember to start small, with simple and realistic goals:

• Don’t try to modernize the entire application at once.
• Don’t try to change everything (code, database, and UI) at once.
• Try not to underestimate the effort. Remember that there are multiple learning curves involved and an incredible amount of testing to perform.
• Try to set goals that the whole company can relate to, not just the IT department.

Even if you choose a single application module to modernize, it might not be a good idea to act on all three modernization areas at the same time. Go over them one at a time, but always keep an eye on the big picture, so that all the work in code modernization is compatible with the UI changes you’ll want to perform next.

There are a few more things you’ll need to keep an eye on. For one thing, programmers are creatures of habit, so they’ll take a while to get used to new tools and practices. On the other hand, using new technology (or even current technology, for that matter) in a project of this nature will require a particular focus on quality assurance. IT and business people will need to test everything thoroughly, not only because it’s new, but also because it has to fit with the parts that are not being changed. Make sure you take all this into account when you draft the project estimates.

Finally, it’s of paramount importance to keep everyone on board. Your goals must be something to which the whole company (IT, business, and management) can relate. It might seem logical to set a goal along the lines of “redo program X in three service programs,” but the business and management areas won’t have any idea what you’re talking about. Carefully word your goals, so that everyone can understand them. You can leave the details and technical lingo for the implementation plan.