Ready to give your application a facelift? This article will help you understand how to set UI-related modernization goals.

As explained before, there are four ways to approach your modernization goals: replacement, reengineering, refacing, and refactoring. The last article covered the first two, and I’ll now discuss refacing or, in other words, how to “beautify” your ages-old IBM i application.

Time for a Facelift

After all, it’s only fitting: after a certain age, people sometimes seek the help of a plastic surgeon to make them feel better about themselves. Refacing is the equivalent process for your aging IBM i application. As you might have gathered, this approach focuses solely on the UI of the application. The idea here is rapidly improving flexibility and usability from the user’s point of view, without going into major code reengineering processes. The technology has been around for a while, and even people from IBM decided to pull a rabbit out of their HATS at a certain moment in time. (Pun intended—if you didn’t get it, here’s a hint: IBM has a product called Host Access Transformation Services.)

Anyway, changing the UI and nothing else is a quick solution to implement because you’re not going to touch the database or business rules. If you’re wondering if this is putting a coat of paint on an old car and calling it new, then you’re right. However, it can be a good first step toward modernization because it can quickly give a fresh face to an “old and outdated” application. Naturally, a second step that modernizes the code and/or the database should follow. If you’re still not convinced, here’s an example: using a refacing technology, you can potentially move a 5250 green-screen application to a web or mobile application in a matter of days.

Now let’s analyze two different types of refacing:

• Screen scraping—This is the oldest type of refacing. It’s been around for quite some time. Screen scraping provides a “man-in-the-middle” approach between the 5250 green-screen and the new graphical UI. Basically, it translates mouse clicks, drags and drops, and other GUI operations into keystrokes and function key presses. It also scrapes the data sent to the green-screen by the application and displays it in a nicer UI. This is particularly useful when you no longer have access to the application’s source code and want to modernize it.
• RPG Open Access—If you still have access to the source code and want more control over the way the new UI works, then RPG Open Access (RPG OA) is the way to go. I’ll talk a bit more about RPG OA later in the series, but for now, know that this is a free tool. (Yes, IBM initially charged for it, but now it’s free.) It enables you to bypass the 5250 data stream and direct the RPG’s program I/O buffer to the RPG OA handler.

More Than Just New Good Looks

As you might have guessed, a refacing approach has some benefits that can’t be overlooked:

• It’s a quick start and potentially a quick win. Because you don’t need to understand the code or change the business logic, refacing is a fast way to modernize an application’s UI. It’s also a quick win because it might help you get that essential top management support that you’ll need for the rest of the modernization process.
• Only the UI changes. Refacing focuses solely in the UI, without changing the application code at all in the screen-scraping approach or by performing minimal changes in the RPG OA approach. Naturally, limited changes dramatically reduce the risk of “breaking” something that you might not entirely understand: your legacy application.
• It’s a nice prelude to the “real” modernization process. It might be OK in certain circumstances to start and end the modernization process with the UI, but in most cases, it’s simply not enough. Actually, most experts agree that changing the UI is a good first step, but it’s never enough. Business and management will want more. This means that you will need to take the plunge and dive deeper into the application’s depths to fulfill the new requirements.

Just Like Its Surgical Equivalent, Refacing Has Some Risks

I imagine that while you’re reading this, you’re thinking, “Sounds peachy! Let’s start refacing right now!” Well, not so fast…there are a few risks that you need to be aware of:

• It’s nice but slow. After the refacing, your application will look much nicer, but it might also be considerably slower, because both refacing approaches take their tolls on the system. If you don’t change anything else, performance might be severely affected.
• It’s beautifully dumb. The new UI is forced to follow the same flow as the old 5250 UI, which means that some of the old interaction logic might not fit nicely with the new UI. Interacting with a green-screen application is obviously different from interacting with a web or mobile application, but unless you go deeper and change the program’s flow, you’re limited to the existing 5250 UI flow. This limitation will make your beautiful new UI look a little dumb. If you take the RPG OA approach, this might not be entirely true, but it’ll require code changes as well, as I hope to explain later in this series.

Refacing can be a reasonable first step, but it hardy solves the challenges you’ll be faced with in a modernization process. It can be used to gather support, both from users and top management. You can then leverage that support to tackle the next, more-challenging steps toward modernizing your application. Just remember: a fresh coat of paint won’t make your ages-old application new again! You can complement it with one or more of the previously explained approaches or even the one I’ll discuss in the next TechTip: Refactoring.