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.