What are your modernization goals?

Depending on your modernization goals, there are several approaches that are available. What you must keep in mind is that there is not a “one size fits all” approach to the modernization process. This section introduces some of the most common approaches in application modernization, which are easily adaptable with most modernization goals.

Replacement

In this modernization approach, the original system is replaced by a new system. The new system can be custom-made or a commercial, off-the-shelf product. This technique can be appropriate if the modernization costs are high, if a modernization project is under a different approach, or if the existing application cannot meet the business objectives.

There can be many risks in this approach that you should consider. For example:

Reengineering

Reengineering is the modernization approach that transforms the original application into a new form to improve its original characteristics, such as functionality, performance, flexibility, UI, and maintainability with less risk than replacement.

The main difference between replacement and reengineering is that, in the latter approach, you take into account the existing application as a constraint of the steps to be taken in the modernization process. You cannot ignore the old application. Usually, the reengineering approach is a two-phase process:

Reverse engineering

Reverse engineering is the extraction of the high-level processes and structure of the original code into an easily understandable representation. The understanding of existing code that is gained in this phase is vital to the reengineering process. Given the complexity of many of the applications that must be modernized and the lack of existing functional documentation, this process can be difficult. So, there are many tools that can help you in this process.

Here are the key steps that take place in this phase:

Reverse engineering tasks are repeated several times during the modernization process. Do not worry if you are finding it hard to understand the application. As the modernization process advances, your comprehension of the original system increases.

Forward engineering

Forward engineering, also known as “refinement”, is the creation of the new system from the high-level representation of the original code.

Here are the key steps that take place in this phase:

In this process, you should apply preferred practices in terms of design, code, technologies, and tools. Later in this book, you find many tools, techniques, and practices that you should consider while constructing the new application. There are many tools to help with existing program understanding along with tools to help you write code in a modern manner.

Refacing

Refacing is the reengineering of only the user interface of the application. The main objective of this approach is to improve usability and flexibility from the user point of view without having to restructure the underlying code of the application. Refacing is a technology that has been available for a long time. Some solutions are better than others. The one significant advantage of a refacing solution is time to market. Using a refacing technology, you can potentially move a 5250 “green screen” application to a web or mobile application in a matter of several days. This does not mean that you must stop at refacing. This approach can be used as a stepping stone or first step approach. This method can give you valuable time if you are considering a reengineering approach.

Types of refacing

There is more than one way to reface an application. Depending on the degree to which they are going to be applied, some refacing techniques are only superficial and do not require changes in the source code. Other techniques involve minimal changes in the code that handles the UI, but without going into the business logic or database access.

This type of refacing focuses on converting traditional 5250 terminal-based applications into window-based interfaces, web interfaces, or mobile based interfaces. Screen scraping usually works by emulating a user on the terminal. While they are connected, they emulate keystrokes, process the display output, extract the data, and generate a new window. The user sees the new UI while the screen scraping does the intermediation. These technologies are targeted at reading the 5250 data stream and modifying what the user sees based on some merged content that can change or control layout, color, and much more. This is a great approach for applications where you no longer have access to the source code.

Open Access (OA) based UI refacing

For interactive programs, you can also use OA to transform your application. The level in which OA acts is different from a screen scraper. The 5250 datastream is bypassed and the I/O buffer of the RPG program is directly assigned to the OA handler. The I/O buffer can be processed by field name or through a data structure for each format. This offers more flexibility and possibilities over the control and the extensions of your refacing approach. You can find more about OA in 10.2, “IBM Rational Open Access: RPG Edition” on page 467. Using the OA solution enables you to potentially control the UI in a more direct manner from your existing RPG code and pass new data directly from your new UI to your back-end RPG code.

As with every modernization approach, refacing can bring you many benefits in the short term, including the following ones:

Risks of refacing

You have learned the benefits of the refacing approach, but there are many risks that are associated with this approach. You can give a “facelift” to the application and make it look modern to the users. However, the application is still the same inflexible and hard-to-maintain piece of software.

From a performance point of view, the application performance might be affected because it was not originally designed with the new user interface in mind. To perceive real benefits, the UI modernization must be accompanied with a redesign of the underlying code, where you can optimize it accordingly.

Refacing an application does not take into account the design of the UI. The flow and how a user might want to interact with an interface from a mobile or web perspective might be different from how the application is interacted with by using the green screen flow. For example, using a green screen approach might require you to select a menu to see more data, and on the web UI a simple select or drop-down menu might be a much better approach. Understanding the UI flow and interaction requires you to continue down the modernization path.

Refactoring

Refactoring is a variation of reengineering that restructures a code base, improving its internal structure without adverse effects to its external functionality. Refactoring takes a “do no harm” approach, meaning among other things that applications interacting with the modernized system do not have to be changed at all.

The “do no harm” philosophy is ensured through extensive testing during the modernization process. Tests should be automated as much as possible. Ensure that the tests cover all aspects of the application.

Without a full set of tests, the risks of the refactoring increase because you cannot ensure that the new system has the exact external behavior as the original system and that you are not introducing bugs to the system.

Refactoring is the preferred approach when your modernization goals include the following items:

Reducing maintenance costs
Increasing the clarity of the code
Revitalizing the application and enabling it to adapt better to business needs
Reducing the risk of affecting others 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 (It is easier to update the application business logic to be accessed by either different or multiple UI technologies.)

Some refactoring is often necessary regardless of the modernization approach that you choose. This book describes a modernization model that guides the modernization project. Some of the activities that are described in this model are more related to the refactoring approach. You must evaluate whether your project needs these activities.