For decades, many big companies have used mainframes and possess numerous -- for lack of a more diplomatic term -- old applications. As the rate of change accelerates and availability demands increase, companies must find the best way to bring these applications into the light of the 21st century.
Deciding to modernize mainframe applications?
Modernizing an application is probably one of the most difficult decisions to make. These applications -- some written in the '70s and '80s -- still run and perform well. Your business users, under constant pressure to reduce costs and increase efficiency, may take an "if it ain't broke, don't fix it" attitude and be very reluctant to part with the money needed for an upgrade. Most daunting of all, the software may support the core business and changing it amounts to transforming the corporation as well.
Although we like to think software is something ethereal that can't wear out, weaknesses start to show:
- The accretion of undocumented changes, bolt-on upgrades and late-night fixes make maintenance difficult and regression testing ponderous.
- The application is tied to an old piece of technology, be it hardware or software infrastructure that is unsupported, error prone or expensive.
- The application's design doesn't allow 24/7 operation or provide real-time information.
- It can't interface with the Web.
It may eventually come down to a judgment call, but its not one to be made lightly. Next is the task of convincing the executives who hold the purse strings to make the investment.
Reengineer or transform?
After the decision to modernize comes the detailed analysis of what to do next. Should the application be modernized through incremental reengineering to new technology or should it be chucked for something entirely new? A few of the factors feeding this decision include the following:
- The application's size
- The application's interfaces
- The application's database requirements
- The application's audience (back-office employees, customers or both)
And don't think this is an entirely technical decision, because politics will come into full force. First there are those who, for various reasons, have an interest in maintaining the status quo. Opposite them are people who see an opportunity reshape the IT department and build empires. Somewhere in between are technicians who only want to make the right choice, although they can differ on implementation for reasons of their own preferences. It's a tough decision to make, even excluding the human element, because today's technology choices leave more than a few gray areas for people to argue over.
Reengineering takes a more evolutionary and less disruptive approach to change. A phased project can replace the old faults in a system with new technology that avoids the limitations and mistakes of the past. Besides rewriting a system, there are also tools available to teach an old dog new tricks. Some that come to mind are the mainframe Web-enabling tools or bridges that allow old code to access new services or databases.
There are several problems with reengineering. First, it can take a long time, especially with a slow, incremental approach. Second, even after all that time and investment, you may still not end up with what you wanted. Third, sometimes an enabling tool may be a band-aid for a more fundamental problem. Besides, sometimes the best thing to do is make a full break from the past.
Transformation is the "back to the drawing boards" approach; nothing is sacred, nothing is set in stone. Designing from scratch opens up a lot of exciting possibilities for platforming, infrastructure and even business processes. In addition, you can study your competitors, figure out what they're doing and learn how to do it better. A well-executed transformative approach leaves the enterprise with a shiny new system incorporating the best practices of the day, ready to serve for years to come.
Of course, transformation comes with its own set of problems. With everything up in the air, there will be tremendous wrangling over technology and infrastructure even before the first line of code is written. Riding too close to the bleeding edge of technology could lead to a morass of problems or a dead end for which there are no easy answers. As with any revolutionary change, disruption is inevitable, so IT and the enterprise must be prepared to weather a few stormy days. In addition, the old system worked well because of the investment in years of manpower and experience. A new system will have some growing pains in applications and operations, and some mistakes that were fixed 20 years ago will reappear. Again, be prepared for a few rainy days.
One size fits all?
At the risk of sound wishy-washy, I'm not sure where I come down on the reengineering versus transformation argument. There are too many variables for one pat answer. An enterprise's best bet is to leave the decisions to a set of more or less disinterested technicians who can keep an eye on everyone else in the monkey house. And, as we all must remember, today's technology is tomorrow's kludge. As you design the new system, keep a picture in your mind of the next generation of programmers asking themselves, "What were they thinking?"
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
Did you find this helpful? Write to Matt Stansberry about your data center concerns at mstansberry@techtarget.com.
