Having an idea of how to set reasonable modernization goals is not enough. So if the last article left you wanting more, this one will provide.

Now that we’ve looked at a few guidelines of the modernization goals in the previous article of this series, let’s analyze what these goals can include. According to the IBM Redbook Modernizing IBM i Applications from the Database up to the User Interface and Everything in Between, modernization goals can be divided into four major categories:

• Replacement
• Reengineering
• Refacing
• Refactoring

I’ll cover the first two here and continue the discussion in the next article.

Just Throw the Application Away and Start Again (?!)

Having said that, let’s start with replacement. This is the easiest to explain: you replace your existing system with a new one. However, an application replacement process can also be the most unpredictable type of modernization process, because it may hide several risks:

• Functionality loss—Typically, an off-the-shelf application will cover only 60 to 75 percent of your needs. Such a loss of functionality may seriously affect the company’s business. Additionally, the work required to implement the remainder of the functionality might not be known up front, which increases the risk and overall cost of the process.
• Training—A new application will require an extensive amount of training, not only for end users, but also for the IT staff. Even if the cost of the training is included in the application price, the loss of productivity associated with the learning curve will also affect day-to-day service levels.
• IT landscape impact—The “new kid in town” might present you with unexpected challenges: different backup and recovery methodologies, new operating systems, different databases, or new interfaces, just to name a few. This will cost you money and time, so be careful.

Reengineering Is a (Sometimes) Fun 100,000-Piece Puzzle

The second category, reengineering, can mean one of two things:

• Reverse engineering
• Forward engineering

Despite its fancy name, reverse engineering is simply extracting the high-level processes and structure of the original code and forming them 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. Fortunately, there are many tools to help you in this process. For instance, UML can be a very powerful tool in such a scenario because it allows you to represent several perspectives, from the more functional (use-case diagrams and activity diagrams) to the more technical (class diagrams for database representation and component diagrams for the interfaces between the different parts of a system, just to name a couple). There are 14 UML diagram types that you can use to model an application’s structures, behavior, and even business processes. I won’t discuss UML in this article, but it’s an interesting and useful subject that I recommend you learn about.

There are three key steps to take in this initial phase:

1. Generate a structural representation of the code that helps you easily understand it.
2. Start mapping that representation to business functions. This will help you identify reusable business rules that can be extracted for modularity.
3. Build an architectural representation of the application, using UML for instance, so you can start to understand the application as a whole.

Reverse engineering tasks are repeated several times during the modernization process. Don’t worry if you find it hard to understand the application; after all, there are probably years or even decades of code/philosophy/programming style (in some cases, undocumented) changes in it! As the modernization process progresses, your comprehension of the original system will increase. You’ll eventually get to a point where you know what you need to know about the application and can decide what you need to modernize: the source code, the UI, the database, or a combination of the three. Just don’t try to do it all at once, as I explained in a previous article.

Forward engineering takes a different approach. In short, it’s the creation of a new system, based on the high-level representation of the original system’s code. The process starts in a similar way to reverse engineering, but then it diverges:

1. Generate a structural representation of the code that helps you easily understand it.
2. Define the functional transformation from the original to the new application.
3. Write the new code.

The first step is pretty obvious, considering it’s the same as the first step in the reverse-engineering approach, so let’s skip straight to the second one. A functional transformation is the set of functional changes required to accomplish the goals that were set for the application. It can include performance improvements, database restructuring to provide flexibility, and so on. Finally, writing the new code should entail applying new practices in terms of design, code, technologies, and tools. Don’t go falling back into old habits that will only hinder the process!

We’ll stop here for now. The next article will address the refacing approach.