In-Depth

You've Been Left a Legacy—Now What? (Part 1 of 2)

IT modernization projects help you deal with old application ghosts before they spook the bottom line. We examine project analysis and planning issues.

• By Ed Olmstead
• 07/19/2005

Who says you can’t teach an old dog new tricks?

According to industry analysts at Gartner Group and IDC, more than half of the world’s business is still handled by “old” COBOL applications. In fact, analysts estimate that better than three-fourths of Web-based programs now trigger some legacy application or database. That’s a lot of old code—nearly 200 billion lines of COBOL by some accounts.

Considering all that, the issue of when and how to deal with these old legacy applications and databases looms large for every IT manager. The problem, however, is deciding just how to navigate these modernization initiatives and knowing exactly where the risk/reward horizon lies.

When an organization embarks on an IT modernization project, change is inevitable. Many aspects of the IT infrastructure, IT processes, and business rules, along with the requirements of internal and external customers, must be identified and included in the modernization plan. To be successful, the effort must anticipate and address the changes that occur across the organization, not simply those in IT. In this article, I’ll look into the issues of analyzing and planning an IT modernization project. Next week, We’ll cover the best approaches for controlling and managing a project.

The object of any IT modernization project is to provide better and faster information to all aspects of the enterprise while preserving the business rules that provide a strategic benefit to the organization and a competitive marketplace advantage. Well-planned, well-managed modernization offers tremendous benefits: cleaner code that’s easier to maintain, lower costs, and greatly improved overall performance. On the other hand, if not planned correctly, the project is almost sure to end in disaster. The importance of planning can’t be overstated.

The first step is to identify and understand exactly what your IT assets are and how they interact. Don’t assume anything—analyze it all. Armed with this information, you can identify what’s driving the current (or possible future) change. This knowledge is essential to defining and controlling the scope of the project. Start by answering a few basic questions:

• Are improvements required in our time-to-market reaction time?
• What do our external customers expect?
• What do our suppliers need to be more efficient?
• What do our internal users need to be more productive?
• What business processes can be improved or eliminated?

Once you know your drivers, you can set out a detailed project plan with activities that must occur prior to, during, and after modernization.

Establish Your Project Goals and Stay Focused

Gaining management “buy-in” is key to the overall success of your project. This translates into the creation of a realistic project plan and schedule, realistic expectations, and a quantifiable risk assessment. Know what you want to accomplish and don’t let competing wants get in the way.

You should, however, expect modifications as the business climate changes over the life of the project. These changes can come in two flavors: business and technical. Let the business drivers direct the technology decisions. Technical changes are hard to justify on their own—they usually come about as a result of some business driver. Be ready to adapt as the need arises.

Do an IT Audit and Global Assessment

You would be amazed at how often this critical step is taken for granted. Regardless of what you think you know about your infrastructure and how it all works together, the only way to know for sure is to do a complete audit—a global assessment of all your IT assets.

Identify all source code, assess how it relates to other code, databases, job control, and external applications, identifying interface and future data-bridging requirements. You will most likely find object code with no source, production jobs stored or executed from non-production libraries, as well as some obsolete code in your production environment. This audit inventory, combined with a clear set of business objectives, will allow you to plan and control the project’s scope, schedule, and cost.

Consider the Impact of New Technologies

What new technologies will you introduce to support the business objectives and what training will be required? If you are moving from COBOL on a mainframe to an emulation environment on UNIX you may need to retrain your staff because the two environments look the same on the outside, but they’re very different ”behind the scenes.” If changing languages, the retraining requirement is even more significant.

Take a hard look at the benefits of any new technology versus re-hosting current applications on newer, more flexible platforms. The learning curve and initial loss of productivity should be factored into the project plan.

Be careful not to lose the business knowledge of key IT personnel who might be reluctant to accept the new technology decision. Migrating the IT staff to new technologies is every bit as critical to the success of the business as the technology decision itself.

Select the Best Modernization Approach

Pre-packaged software always seems like an attractive option, but that’s seldom how it works out. There are three types of modernization you need to consider: non-invasive re-use, automated migration, and system reengineering.

• Non-invasive re-use lays new functionality (such as Web Services) on top of the existing application and re-uses the application as is. This approach carries little risk and is the least costly, but it only solves a subset of modernization needs.

• Automated migration involves changing database management software, hardware platforms, and (sometimes) programming languages in a highly automated fashion. There is more risk with migration solutions and additional cost, but the results are likely to have a greater positive impact on the system and will provide the foundation for the development of additional system functionality and future enhancements.

• System Reengineering requires tools that automatically mine the existing systems, then redevelop new components using the mined information. This is even more costly and carries a much greater risk, but reengineering is typically the only way to properly reconstruct a maintainable application using the new system architecture.

Another concern is long-term maintainability of the new environment. This relates to the quality of the resulting code and how difficult (and expensive) it will be to maintain. How much of the old syntax and architecture will remain after the conversion? If the new code is something of a hybrid straddling the old and the new, your staff should be familiar with both.

For example, if you’re attempting to automate the change from COBOL to Java, it may look more like cleaned-up COBOL than native Java. You may need someone familiar with the architecture of the COBOL source even though he/she might be writing in Java. The bottom line: consider whether the resulting code is easy to maintain without the knowledge of previous technologies.

The insight gained from analyzing code maintainability and estimating performance of the target system will provide significant input to the decision as to which of the three modernization methods is most appropriate.

Next week: Best practices for managing modernization and anticipating change