Here’s the final “R” of the quartet I’ve been discussing: Refactoring and its proposition is so obvious that we usually forget about it. Note that I said obvious, not easy. Keep reading to figure out what I mean.

Finally, let’s discuss the final R of the Modernizing IBM i Applications from the Database up to the User Interface and Everything in Between IBM Redbook modernization goals: refactoring.

“Do No Harm”

Refactoring is a variation of reengineering: in this approach, the application’s code is improved in such a way that the functionality and interfaces with other applications are not affected. In other words (the words of Hippocrates), “do no harm” is also refactoring’s philosophy. To make sure that you really did no harm to the application or its operating context, extensive testing is required. Because tests, particularly of the magnitude required here, are very time-consuming, they should be as automated as possible. If your modernization process also included a UI modernization, there are many tools that can easily map and thoroughly test the interaction flow. There are also tools that can do the same for green-screen applications, although they are restricted to the boundaries set by the type of UI, which makes these tools less flexible.

You can gain the most from a refactoring approach when your requirements include some or most of the following:

• Reducing maintenance costs
• Revitalizing the application and enabling it to adapt better to business needs
• Reducing the risk of affecting other applications by modernizing an application
• Keeping the application in the same platform and language as the original
• Using the existing skills of your current programming force
• Allowing user interface flexibility (making it easier to update the application business logic to be accessed by either different or multiple UI technologies)

Because a refactoring approach takes the existing code base as its starting point and works to improve it—making it clearer, more maintainable, and more flexible—it will inherently reduce the application’s maintenance costs and prepare it for further evolution. This can present itself in the form of new business requirements, new UIs, or something else the users come up with—and you know how creative users can be!

The “do no harm” mantra needs to be enforced by extensive tests to guarantee that the existing functionality and interfaces with other applications are not affected by the changes. Considering that these two sets of tasks (developing and testing) will be performed by the existing team (IT and business users, respectively), over the existing application, there’s a hidden bonus: your company will end up with a revitalized application and a group of people who know a lot about it!

RPG Academy Has (Mostly) Been About Code Modernization…

Now that you know a bit more about why and how to modernize your applications, the following TechTips will focus on database and UI modernization. You might be wondering what happened to code modernization. Well, it took us quite a lot of TechTips to get here, and most of those them were, in one way or another, about code modernization:

• The first step was to move from OPM to ILE and from there to free-format RPG.
• This was followed by another step of paramount importance: proper code structuring and documentation.
• Finally, learning more about the ILE’s debugger can dramatically improve testing and troubleshooting application errors.

…But This Subseries Hasn’t

Before moving on to the next big topic in the modernization discussion, let’s stop and make a quick summary of what was discussed thus far in this subseries.

We began with a discussion of what “application modernization” means in IBM i’s context. In short, it means changing a combination of three things in an application:

• The source code
• The database
• The user interface (UI)

For the business, however, modernization means something else:

• Relevant cost reduction
• Application performance improvements
• Application agility improvements (quicker and easier responses to business requirement changes)
• A modern and user-friendly UI
• An easier-to-query database

There you are, dear reader, stuck in the middle, with a hot potato in your hands, trying to figure out the best way to address the business and IT needs. Is your application worth modernizing? There are a few questions you need to answer to determine if the application provides real value to the business:

• Is the business success globally of companies using the platform relevant?
• Does business functionality encapsulated in the legacy application provide a competitive edge to the company?
• Does the total cost of ownership delivered to clients, suppliers, and partners pay off?
• What are the costs and risks of the viable alternatives?

Most of the times, the answer is this: “Yes, my application is worth modernizing, but it seems a hard process. What are the benefits?”

There are three types of benefits. First, for the IT staff:

• Structured and modular applications require less maintenance time.
• ILE code, if designed properly, is easier to troubleshoot.
• Modular applications are easier to integrate with other applications.
• Modernization opens new doors to programmers.

For your boss:

• It’s easier and potentially cheaper to find people to maintain a modern application.
• Costs related to a “fresh-faced” application are easier to justify.

And finally, for the company:

• Structured and modular applications may give the company a competitive edge in the market.
• Modernizing an application may prevent considerable investments in new systems.

In short, a modernization process reduces operational costs, might improve motivation, and reduces the need for investment in new systems. Smiling faces all around, right? Well, there’s a catch: this type of process has its perils. A critical step in the modernization process is setting the right goals. Considering that there are three interconnected aspects to modernization, there are different goals you can set. The modernization approaches generally fall into the following categories:

• Replacement
• Reengineering
• Refacing
• Refactoring

Depending on the business and IT needs, you’ll set a combination of goals taken from one or more of these categories. Note that nothing is carved in stone, and each modernization process is unique. For instance, some might consider a refacing approach to be a complete waste of time, while others might think that it’s more than enough to solve their problems.

It’s up to you, your users, and management to determine the best way to tackle modernization.