Feb 1 ’05
Life After Conversion: Preserving the Value of Legacy Applications
Many organizations still rely on IDMS, IMS, Adabas, Datacom, Supra, Ingres, Informix, and similar database technologies to run strategic applications because they’re stable, reliable, and fast. They may also be:
Difficult to integrate
Proprietary in terms of languages and data access syntax
A maintenance challenge due to a lack of skilled resources for support
Expensive due to high or escalating license fees.
Most successful, well-established organizations still rely on legacy database technology to run their businesses. These organizations were on the leading edge of technology as they implemented their database management systems 20 to 30 years ago. Some of them are likely still on the leading edge of technology with their use of one or more relational databases such as DB2, Oracle, SQL Server, Sybase, or Universal Data Base (UDB).
Most organizations that replace legacy databases and applications do so because:
The license fees for the aging software are high and rising.
Teams of personnel skilled in the older technology are difficult to find, which has caused the older applications to stagnate.
The data must be easily available to other applications and platforms.
Web access is required.
So, what options are available for organizations that rely on legacy technologies? Is there really a fine line between “stable, reliable, and fast” and “aging, closed, and expensive?” Or, are these two sets of adjectives mutually exclusive (see Figure 1)?
Maintain the Status Quo
Organizations satisfied with their current application functionality, license fees, productivity tools, integration capabilities, and application “look and feel” may find that continuing to maintain their legacy databases and applications is a good choice. There’s always the low-risk option to continue “as is.”
Most organizations have at least con sidered replacing legacy processing. Many were deterred from doing so by the arduous nature of the replacement process. It’s a huge time and cost investment and it’s possible that the resulting application and database won’t perform as well as the legacy system. So, if it’s not broken, why fix it?
Redevelop, Rewrite, Re-Engineer
Software rewrites let organizations introduce new capabilities into existing software while also updating the legacy databases and languages. Depending upon the extent of the functionality changes, these projects may be considered redevelopment projects, rewrites, or re-engineering. For this discussion, we’ll use rewrite to represent all three terms.
There are many advantages to a rewrite. Rewrite projects can be successful when the development team is knowledgeable about the:
Process and requirements
Former legacy database design and application languages
New relational technology and tools.
Some organizations have been working toward a goal of eventual replacement. New applications and major enhancements are developed using the newer relational technologies with easier integration and a more open architecture. The result is usually a core set of strategic legacy databases and applications around which the newer applications are built. The legacy databases became the hub of the wheel many years ago, and the newer applications and databases have been added as spokes.
Other organizations attack selected applications that require major enhancements. They redevelop these using newer technologies and tools to replace all the functionality with new functionality. By performing this rewrite, they can enhance and update the databases and applications during a single project lifecycle.
Rewrites also have downsides. Project costs and timelines for an application rewrite are often difficult to estimate. Attempting to define the resource and budget requirements upfront can be like a box of chocolates; you never know what you’re going to get! Rewrites require the technical team to know and understand the language of the original application as well as the new languages. The first phase of a rewrite project can include many person months of analysis, research, discovery, and planning. Project plans often must be detailed and all-inclusive. Standards are critical to producing new code that gives harmony to the new applications. Testing is often difficult and time-consuming because comparing the test results of new and old systems is like comparing apples to oranges.
Purchase a Replacement
Replacing legacy databases and applications with off-the-shelf packages presents many opportunities to redefine business processing standards and upgrade the software that runs a business.
Purchased packages provide additional flexibility often lacking in applications written in-house. Packages often include capabilities and features that reduce an IT department’s “enhancement backlog” to near zero. They eliminate the legacy databases completely. Purchased package installation is fast and not overly expensive. The price for the new software is easy to define. Purchasing a package can eliminate many of the “unknowns” associated with a rewrite. The installation and implementation time is often less than a rewrite. There are many benefits to purchased packages.
There are downsides, too. Selecting the right replacement isn’t simple. The selection process requires detailed analysis of the current applications and databases to ensure that critical functionality is still available in the purchased package. Mapping existing data from the legacy database to the new database is never easy. Terminology in the legacy system never quite matches up with the new system. Writing the programs to extract the data from one to the other is an often overlooked task. Defining automated methods to verify an appropriate mapping is often impossible!
Once the replacement package is selected, purchased, installed and populated with the existing data, attention shifts to redefining the business and retraining users. Replacement package projects may move on schedule into this phase of the project, and then be canceled because the business itself couldn’t change enough to match the purchased software! Even with the best up-front analysis, “selection by committee,” and total buy-in from everyone, problems will exist if the purchased software can’t conform to the business and the business can’t conform to the package.
Some applications are so customized to meet unique business requirements that an off-the-shelf replacement simply may not exist. Some organizations have developed in-house software that sets them apart from their competition; it contains many features that help the organization remain ahead of the pack.
Organizations satisfied with their current application functionality but worried about license fees or shortcomings in their current productivity tools, integration capabilities, or application look and feel may find that a conversion to newer relational technology will resolve many issues and pave the road for the future.
“Conversion” has historically been used as another term for “rewrite.” This may or may not be correct for a specific project. If the project’s purpose is to change the database, application language or both, but not to materially change application functionality, then the project is truly a conversion. If the project’s purpose is to change the application functionality, database, or language, then the project might better be labeled a rewrite.
Manual conversion projects to replace legacy technologies have been undertaken for many years. These projects aren’t intended to provide additional functionality to users, but are intended to solve the underlying technology issues associated with non-relational processing. Some organizations have successfully carried out conversion projects to completely remove their legacy databases and applications. Many organizations have used manual conversions to move some of their smaller or less complex applications and databases to newer technology.
Manual conversions aren’t easy or always appealing because:
It’s often difficult (or impossible) to estimate the time and cost requirements.
They are generally time-consuming and labor-intensive.
The assigned technical team must be knowledgeable in both the old and new technology to ensure that the same functionality is carried forward.
The results are often unpredictable because every line of code is “new” and it’s difficult (or impossible) to test every aspect of the application and exercise every line of code.
Automation adds speed, uniformity, accuracy, and consistency to the conversion process. With automation, the number of technical resources, the conversion lifecycle, and the project costs are all drastically reduced. The skills of the technical team members become far less critical to success. Program logic remains intact and not opened up to human interpretation. If the conversion automation is highly advanced, then the timeframe between project conception and integrated testing should be a matter of days, not weeks, months, or years (see Figure 2).
Conversion vendors can assist with the conversion process in various ways. Some vendors provide technical teams to carry out manual conversions. Some provide technical team members and limited automated tools. Others provide highly automated conversion tools. Selecting the right vendor is important.
The code generated by an automated conversion tool should be easily maintained in the new environment. The architecture of the applications generated by the automated conversion tool should be multi-tiered to provide flexibility in the new environment. The conversion vendor should be able to guarantee performance and functionally in the new environment.
Create a checklist of the factors important to you and your organization. Review the vendor’s generated converted code before selecting a conversion strategy. Check the background of the conversion vendor and measure the vendor’s success rate with conversion projects. Talk to references. Ask questions. Be sure you’re comfortable with the vendor’s level of expertise and project management style. A process-oriented vendor with a high level of automation can provide a fixed bid for your conversion project and you should insist on that.
The downside of an automated conversion is minimal if:
The goal of the project is to keep the application functionality the same while eliminating the legacy technology.
The correct conversion vendor and vendor solution is selected. (The downside is huge if the wrong conversion vendor or wrong solution target are selected!)
Organizations have options for addressing and replacing the aging technologies around which their business is built. Business and technical goals should drive the solution selection.
Purchased packages and rewrite projects can be viable options. Today’s automation makes data and application conversion both technically and economically feasible and even desirable.
The value of the data locked in legacy applications and databases is huge. The investment in the design, development and maintenance of these legacy applications and databases is also huge. These two factors alone create a powerful incentive to preserve the proven processing capabilities through conversion rather than re-creating the functionality through purchased packages or rewrites.
If your existing legacy applications perform efficiently and effectively meet business needs, then the “life after conversion” for these legacy applications may well be another 20 or 30 years! Converting legacy application and database designs to newer technology, with newer tools and more robust processing capabilities, will extend the life of these systems well into the future.