This first stage of legacy application modernization leads to predictive, preventive maintenance that maximizes program quality. This stage includes understanding the existing applications, upgrading existing code to a consistent release level, and removing coding anomalies. For many organizations, accomplishing this stage is made easier through the use of automated application tools, especially when applications include programs that have been around for many years. Whether or not you choose automation, this stage is a prerequisite for the stages to follow.
UNDERSTANDING EXISTING APPLICATIONS
Before beginning the modernization process, the first task is to understand which applications need the most help. This task includes gathering statistics about size, complexity, the amount of dead or unused code, and the amount of bad programming for each program. In addition, in selecting which programs to improve together, selecting the ones that affect common data is a critical step when planning to move through all of the modernization stages, including reengineering for reuse and/or migration.
The consequence of skipping this step is a lack of assurance that resources are applied to programs in the order of greatest return. Programs high in complexity, too big to manage, and that have had the worst programming habits applied should be cleaned first. They are likely to be the ones that cause the biggest problems. Even if they have not caused recent problems, if anything goes wrong in the future, they will be the hardest, and take the longest, to fix. This could be a costly oversight during a time when system downtime is measured in high dollars-per-minute, or -second.
As programs are understood, if they are not grouped into projects correctly, there will be more rework in the future. This is especially important when components and business rules are planned. All programs with logic that affects common data must be grouped together or it will be impossible to rationalize all redundant logic into newly reusable executables.
UPGRADING CODE RELEASE LEVELS
Some organizations have avoided upgrading legacy programs that have been running in production. In some cases, the source code across applications may even have different language release levels. Before any program cleanup can begin, code must be at a consistent language release level. The consequences of skipping this step are:
- Verb and other language variances between releases could make it difficult to remove program coding anomalies according to consistent standards
- The inability to recompile all modernized programs with the same compiler
- Difficulty linking compiled programs together as cleaned applications because of compiler variances.
In some cases, there may not even be compilers available to recompile the cleaned programs.
REMOVING PROGRAM ANOMALIES
Each year, approximately 80 percent of most application budgets is allocated to software maintenance. In the past, the application’s maintenance life cycle has been predominantly driven by defects identified in existing legacy applications. Often, these defects were isolated and corrections were made while avoiding any disruption to the code that was still working. The application was then tested and sent to production. This “patch” process often resulted in what we jokingly call “spaghetti” code. Today, we are paying the price of making “it work” — the key criteria for putting code back into production. We now must clean up the spaghetti.