The Long and Short of Modernization
June 6, 2011 Dan Burger
Companies that take on application modernization projects almost always have a great notion. Many of those expectations have come up short. The quickest way frequently doesn’t deliver the hoped for objectives and what often is realized is that more effort than expected is required. Alison Butterill, IBM‘s application development offerings manager for Power Systems, has seen it play out many times. Taking care of the interface is the easy part, she points out, but she also offers advice to make back-end transformations much easier.
The single biggest driver for modernizing applications continues to be users who don’t like the way an application looks. Butterill refers to this as “the way an application behaves at the glass.” Some people might call this putting lipstick on a 5250 screen. More universal terms are screen scraping or refacing, which means putting a graphical image on a local device and most often this is a browser. In most cases, this does not involve manipulation of code, although could include building macros, adding extensions, calling APIs, and triggering screen displays by mouse clicks. The functionality remains the same, but the application has been enhanced with charts and graphs and pictures. Workflows can be improved.
This level of modernization success can be achieved pretty easily and pretty fast. There are numerous products available for this and it’s close enough to a push-button operation to be called just that.
But for many companies the goal is to create more flexible code as part of the modernization process. Flexible code is another way of saying interoperability. And to get to the interoperability stage requires some “code mining.” Butterill explains this as taking the existing code and assembling it into a new architecture that’s conducive to integrating pieces of code from a mixture of languages. It’s not a single-system world anymore. And it means IT decisions must be made that take into account where companies want to be strategically.
Butterill sees many companies being shackled by old habits.
“You can’t do modern development with old tools,” she says. “If you still have the old tools for writing RPG or COBOL code, you need to move forward. Move to modern compilers. Get to RPG IV, ILE COBOL and ILE CL.”
The topic of compilers is a topic of inertia, which in many cases has slowed to a crawl. As new compilers have been introduced, adoption levels have lagged. One factor is the familiarity with the compiler on hand and the old “if it ain’t broke, don’t fix it” or “don’t buy technology just for the sake of technology” viewpoints. Considering whether old code should be re-architected hasn’t been discussed or has been dismissed as not being a priority.
Now, at many companies it has become a higher priority.
“You need to modularize, which means taking programs with thousands of lines of code and breaking them into functional components–user interface, business logic, data, and maybe print modules,” Butterill emphasizes. “It’s important to isolate the functions. Once it’s modularized, it’s easy to pull out a module and replace it.”
Companies that have been doing modernizing along the way–those that converted to RPG IV, for instance–are ahead of the game when it comes to the latest stage of modernization.
There’s work involved here and IT staffs that have rolled up their sleeves know there’s no push-button solutions. In most circumstances, the day-to-day IT load gets in the way of taking on modernization projects that go beyond refacing. The real world constraints inhibit change and force many companies into relying on the same old methods and patterns in order to get things done.
Executives often have a difficult time understanding the scope of the project. Inadequate resources are major obstacles. A lack of time, sometimes a lack of skills, and a lack of modern tools combine to sink projects before they ever get under way.
“Education of staff tends to lag behind where it should be to be,” Butterill notes. “When minimal education and skills transfer combine with expectations to create something incredible in a week, the outcome will not likely be good.”
The tools for re-architecting the back-end code are not typically found on the workbench of RPG programmers who began their careers with the AS/400 or the earlier System/3X midrange systems. However, they are the logical choices to take on these tasks. Many have successfully done so. Many more have yet to dive into this pool.
Butterill describes this as a change application development procedure from program driven to event driven. There will be invasive changes to the code, which is why it needs to be modularized. Different programs will control which pieces of code are called. This is where the re-architecting happens.
“When things are event driven, they result from a user’s choice rather than from program logic,” she explains. “I start thinking about how I’m going to restructure my program to support a different model because it is becoming a piece of my application not the driving force.”
“For example, RPG code today might have 10,000 lines of code. It’s the driver. It decides what happens. It decides what is written to the end user. The way of the Web is that the user has control and applications are responsive to users. You want to modularize code and make it responsive to events that are happening based on user input. Rather than control residing with the RPG code in the application, it resides in a separate environment, not in the basic program function. What we used to think of as basic program function is now divided into logic modules or procedures if it’s RPG. The controller decides which one to call.”
This is where the database comes into play. And as more people look at modernizing and modularizing back-end code, the topic of database modernization comes up more often as well. It probably doesn’t come up often enough though. Companies that haven’t done any work on their databases in 10 or more years need to make sure they can support their modern business applications. When applications include a variety of graphic interfaces, involves multiple programming languages, and brings Web services into the equation, it is good advice to make sure the database design will support those things.
“There are lots of customers who have not stayed up to date on the things the database offers,” Butterill says. “Some people have perfectly tuned databases that are ready to go when a modernization project takes shape. This is about designing the structure, understanding the relationships between files, and architecting the database.”
“If I was looking at a modernization project strategically, I’d look at the database as a consideration. Not the consideration in the project, but a consideration. Maybe the database is in a state that is not perfect, but it will work. And it will continue to work for a while, so I am going to focus on the programming aspect. Or maybe my programs are OK and my first step toward modernizing is my database needs fixing first. You can’t go forward with old database structure. You may not need to restructure it, but you need to understand what’s there in order to build on top of it.”
So what are companies doing to get through modernization projects?
With no hesitation, Butterill says success is based on the business reasons for modernizing. Everyone must understand the business objectives. Her advice includes getting all the stakeholders involved, which means the end users of the application as well as the management team and the developers.
She also suggests getting some outside help from IBM or the third-party modernization tool vendors, where experience in these projects runs deep. You may find you have the in-house skills to complete the project or decide that outside assistance in the better plan.
NOTE: Alison Butterill will be presenting four sessions at the OCEAN Tech Conference, Friday, July 22, in Costa Mesa, California. A session schedule can be viewed at the OCEAN User Group website.