The task of modernization has been lurking in the shadows of IT for a decade. But just what is application modernization? Industry luminary Trevor Perry says, "Modernization is our jobs. It's what IT does. We improve access to information for the businesses we work for." But what are the traits of a modern application? I believe a modern application has five basic qualities:

1. It has maintainable and testable code.
2. It is modular and component-based.
3. It provides a rich user interface.
4. It uses the Model-View-Controller (MVC) design pattern to separate presentation, flow control, and business logic.
5. It is responsive to new business requirements.

Why Bother?

Any way you slice it, modernizing applications is costly. But the reality is that not modernizing is more costly. Let me explain: A recent Gartner Group report says that 60 to 80 percent of all software development is enhancements to or maintenance of existing projects. As a result, there is a 10 percent increase in legacy code per year. Obviously, the effort required to enhance and maintain those legacy applications escalates as time goes on.

Code is read far more often than it is written. Thus, what sense does it make to bloat unreadable code at a rate of 10 percent per year? Reducing application maintenance costs is arguably the biggest reason to modernize. Also, by making the applications modular, your shop will be able to respond more quickly to business requirements.

Another huge benefit of modernization is that it improves interoperability with other applications and technologies. The technologies range from the various web languages (e.g., Java, PHP, EGL, .NET, Grails) to the grand and glorious SOA.

Modernizing Coders

The task of modernization can be broken down into three contexts: UI, code, and coders. I'm going to forgo discussion about the selection of Java, PHP, EGL, .NET, or Grails for the UI tier because, unless you are going to rewrite your RPG in those languages, you will need to modularize your RPG before you can add a web front end. Certainly, you can modernize your UI quickly with HATS and WebFacing (WDHT). But WDHT is the Botox of the modernization world. It is quick and easy with sometimes remarkable cosmetic changes, but behind that puffed-up face there will always be the same old person. If you really want to make over a person (or application), you have to start from the inside. That means attitude, knowledge, and organization.

Attitude should come from personal fulfillment, but it can also be coerced from effective management. Knowledge is acquired from experience or education (more on education in a moment). And organization, in terms of application modernization, relates to both the micro-level when restructuring a program and the macro-level when planning an attack for modernization.

The most common training strategy is formal education. However, the best training is mentoring. Sure, conferences and formal classes are worthwhile, but mentoring virtually guarantees that new techniques can transform from knowledge to functioning business code. If you don't have internal modernization expertise, get a consultant. Just be sure to choose one who has mentoring skills. Be aware that, with the advent of WebEx, GoToMeeting, and alternative web conferencing tools, your consultant does not have to be on site. Furthermore, with web conferences, the consultant does not have to be full time. Two hours of mentoring per day can maximize your training budget's ROI.

Immediately subsequent to formal training, or at the onset of a mentoring program, you should promote (perhaps enforce) use of a modern IDE (such as RDi or its predecessor, WDSc). A good IDE provides tools that are necessary to the modernization process. My favorite RDi RPG refactoring facilities are Application Diagram, search and replace, online help, outline view, and RDi's streamlined edit and compile process. As I covered in "Grokking Software Development" (August 2007, article ID 20979 at SystemiNetwork.com), program comprehension can be substantially improved with the use of visual tools such as Application Diagram (Figure 1). Search and replace (especially with its support for regular expression) makes widespread code changes easy. The online help jogs my RPG-syntax memory and assists me with new languages constructs. The outline view lets me quickly move around a source member. Also, I am more productive with RDi's edit and compilation facilities.

An essential organizational task of modernization is getting your developers out of their coding caves and into a collaborative development strategy, complete with code reviews. Code reviews are a standard part of modern software engineering methodologies. They are used to improve the quality of code before it is put into production and are also an excellent way to persuade developers to use new techniques.

Moreover, RPG developers can greatly benefit from learning another language — one that forces modular development. I'm not suggesting replacing RPG. But exposure to other languages can often pull coders out of the bad habits they formed before RPG evolved with ILE. A developer can significantly benefit from a course in a language he or she may never use (e.g., Ada, Ruby, or Smalltalk).

Code Moves to Data

I'm not just picking on RPG. Most code over a decade old can profit from modernization. The preponderance of HTML that one finds on the web, for example, needs to be converted to XHTML and its look and feel moved to external CSS. But whereas HTML is probably not on your transformation list, your database should be. A large percentage of 20-year-old RPG was written to do things that can now be done with database technologies. I'm talking about things such as table relationship management and foreign key constraints. Besides reducing the requirement for code, modernizing your database can also make it easier for web programmers to access application data. Many available techniques let you make huge improvements to your database while retaining existing record formats so you don't have to recompile your RPG.

Global vs. Gradational Modernization

There are two basic strategies for modernizing code: globally or gradually. Global modernization happens when management backs the project with bucks. You get to bring in consultants and purchase a modernization tool set such as Databorough's X-Analysis. Gradational modernization is when you refactor code on an ongoing basis during normal business development.

The reality of the global modernization approach is that management often cannot back such a concentrated effort, even though, in the long run, it is the most cost effective. There are two alternatives to this: Either do nothing and let your code swell beyond recognition or improve your code in a gradational approach. My philosophy is, regard every bug fix or enhancement as an opportunity to improve code.

Consider a change request that might be a 10- to 20-hour project using the same old quick-and-dirty code bloat strategy. My proposal is that you use the request as an opportunity to modernize. Yes, I know. When you first get started with the gradational approach, what would have taken 10-20 hours in a typical monolithic RPG could very well take 80-140 hours to complete. But that time can significantly decrease as you respond to more business requirements. And it will soon diminish to the point where you will be more receptive to all IT requests.

Fear Factor

To be blunt, the biggest reason not to use the gradational approach is a four-letter word — Fear. That's right. Fear. We are scared of making sweeping changes to a program. We are frightened because we can't deduce the impact of those changes. That's why legacy code bloats. Instead of correcting existing code, we add global variables, subroutines, and programs. That way, we know our new code won't affect old code. What we need is confidence. Not false confidence (such as that brought on by alcohol or ignorance) but real confidence with the conviction that your changes can work in production.

The only way to be confident about code changes is automated testing. If you can't figure out how to test code, don't bother writing it. Because there aren't many unit-testing tools available for RPG, I wrote a simple tool (it's merely a set of RPG modules) called iUnit. You can download iUnit from SystemiNetwork.com/code (select April 2007). Instructions for iUnit and how you might write your own testing utilities are provided in "Developing Reusable RPG APIs" and "Testing RPG-based Stored Procedures with RPG" (see Find Out More, below). Note that IBM is working on providing first-class unit-testing tools for RPG.

Your shop should employ the software engineering practice known as refactoring. Refactoring is changing code to simplify or improve readability without changing the result. Automated unit testing ensures that code modifications cannot cause the application to fail. My approach to gradual modernization has four steps. First, write a wide range of unit tests over existing code and run them before any modifications are made. Of course, the tests will fail. Second, make modernization changes, without adding bug fixes or enhancements, and rerun the tests. Third, add tests for the bug or requested enhancement, then run the tests, which will again fail. Fourth, make the bug fix or enhancement and iteratively rerun tests and tweak the code until the tests succeed. Now, consider fear no longer a factor.

Developers need to be bold with their code changes, and another way to promote courage is source control. Without the ability to revert to a prior version of code, programmers can be reluctant to make extensive changes. In "RPG Source Control — for Free" (August 2005, article ID 20205), I suggested that System i shops should use a source-control product instead of relying on manual methods of source control. I also recommended the use of the open-source CVS and Subversion tools. However, by all means consider the various commercial, more RPG-friendly products.

Grokking RPG

When a change request comes in, don't just hack the change — grok the code and modernize. Grok means to understand profoundly and intuitively. In other words, rip the program apart with both your brain and RDi's tooling until you fully comprehend it. If your understanding of the program stumbles because of a poorly named variable or routine, rename it to something more meaningful. But don't forget to run unit tests to prove that your refactoring didn't break the code. Discover business entities (those not already in record formats) and define external structures for them. Refactor the code to use the external entity structure. Recompile and retest.

The first step to modernizing an RPG program is to separate the UI from the business logic. Pulling out the UI and isolating business logic into ILE modules gives three huge advantages:

1. You can create automated tests.
2. You can reuse the modules in other applications.
3. You can more easily interface with web technologies.

After improving the readability of the program (and, if necessary, separating the UI), you are ready to implement the change request. If it requires a change to a subroutine, convert the subroutine into a subprocedure. Remove all possible uses of global variables in the subprocedure, even though that action will undoubtedly force you to add parameters to the subprocedure. (Note that file parameters are available for RPG with V6R1. File I/O was the last vestige of global variables in modern RPG.) With the requirement for global variables removed, the subprocedure can be placed in its own source member and thus becomes a module. Create unit tests for the subprocedure. Question: How did we test subroutines before? Answer: We didn't because we couldn't. Subroutines weren't modular, so atomic testing was not an option. With subprocedures, however, unit testing should be a requirement.

Save the Program, Save the Platform

If management backs a global modernization effort for your company, congratulations! You will be bringing in top-notch tools and consultants to ensure the successful modernization of complete applications. But if management doesn't buy off on global modernization, use the gradational approach. You can begin by doing an empirical study to discover what programs require the most frequent maintenance and start by modernizing those. You can also take my philosophy of using change requests as opportunities for modernization. The point is, over the course of a few years, it costs less to modernize than to put your coding heads in the sand, ignore code bloat, and not modernize. Deal with the fear factor by mitigating risk with unit testing and source control. Get a mentor, enforce the use of RDi, and start code reviews. Just start modernizing today. One of the greatest strengths of the System i is its RPG. Every RPG application you rejuvenate strengthens the platform.

Don Denoncourt is the Groovy Guy at CAS Severn in Laurel, Maryland. Don does training, mentoring, and consulting for Java, Groovy, and Grails.

Find Out More

System iNEWS Articles at SystemiNetwork.com

"RPG Source Control — for Free" (August 2005, article ID 20205)

"Developing Reusable RPG APIs" (February 2006, article ID 20395)

"RPG Source Control for Free, Part 2" (April 2006, article ID 20461)

"The Essential Guide to an Effective Application Test Environment" (December 2006, article ID 20747)

"Testing RPG-based Stored Procedures with RPG" (April 2007, article ID 20866)

"Grokking Software Development" (August 2007, article ID 20979)

"Search Source Code with Regular Expressions" (August 2007, article ID 20981)

System iNetwork Blogs

"Two Minutes with RPG Expert Paul Touhy"

Books

Fowler, Martin, Kent Beck, John Brant, and William Opdyke. Refactoring: Improving the Design of Existing Code (The Addison-Wesley Object Technology Series). Boston: Addison-Wesley Professional, 1999.

Ambler, Scott W. and Pramodkumar J. Sadalage. Refactoring Databases: Evolutionary Database Design (The Addison-Wesley Signature Series). Boston: Addison-Wesley Professional, 2006.

Web Articles

Modernizing and Improving the Maintainability of RPG Applications Using X-Analysis Version 5.6 (Click here)

RPG Application Evolution: Transforming Applications (Click here)

Not just a nip and tuck, application modernization extends the lifecycle of legacy code assets (Click here)

How to plan a road map for application modernization (Click here)