A legacy system is one which is one uses old technology and is still in current use due to dependencies that often make it hard to move away from. When it comes to upgrading or adding additional modules to a piece of software this can often pose many problems which can then raise the questions of how to proceed in a way that is both cost effective and beneficial to the company.
As computer technology works its way into many aspects of our everyday lives software has to be engineered to function for those purposes. As the requirements behind these systems change, so do the systems in order to keep up with the changing requirements. These 'legacy' systems can be modified to increase functionality, etc using certain techniques; though it should be noted that there are risks involved in modifying legacy systems. To do so, requires a different methodology to what is usually required in creating new systems, but these techniques are similar in practice.
The main difference between creating a system from scratch, and creating an upgrade, etc for a legacy system is that with a fresh system there is no information already prepared for making system changes. With legacy systems there is already something to work from, and is likely to have some sort of documentation for the system. Another major difference between the development of new and old systems is that legacy software engineering does not need as much input from people inside the target company as new software does. This is due to the fact that the research into the company has already been done, and a detailed idea of what is needed has already been compiled.
It is inevitable in most businesses utilising specialised software that their requirements will change in some way, or other modifications such as bug fixes are needed. In one case study we looked at whilst at University, they originally had a system programmed in COBOL during the 1980's, which was then later expanded using C/C++ for the new aspects on a new server. At this point the existing server using COBOL code was still in use and was interfaced by the new server using an ad-hoc interface (basically meaning it was a cheat in order to not have to make significant changes to the original coding).
The planned expansions for this companies system were to implement a call centre capable of handling account inquiries and transactions, and to allow for a new type of mortgage. The first of these changes would require an interface with the existing relational databases to access accounts, and the second would need to be done as an addition to the original server to allow for an extra type of mortgage.
Polls represent as much as 85-90% of an IT budget for operation and maintenance [Zou02]
As Zoufaly says when describing challenges faced with legacy systems, much of an IT budget is used to keep legacy systems running as they are supposed to. This in itself can create problems for businesses using legacy software when they get to the point of upgrading in that the maintenance costs are likely to increase. This is where a better process of software engineering and quality assurance would have benefited the system. Though it is likely this would cost more initially, it would have the advantage of lowering the cost of maintenance and future upgrades. This is a problem that is commonly faced by many businesses all over the world and one that has been researched into by many software engineering experts and companies in order to better evaluate changing circumstances and lower maintenance systems.
The growth in cost and importance of software to NASA, and the aging of many of the Agency's important software systems, has necessitated software re-engineering efforts [Ros00]
As expressed by Dr. Linda Rosenberg of the NASA Software Assurance Technology Center, the re-engineering of legacy systems is of great importance when dealing with software systems that show signs of age, and may no longer perform all the functions which are required of them. Though in the previous case study the system may not be considered as critical as some of those used by NASA, but the concept is still the same. With an aging system that has been upgraded and patched many times, the cost of maintenance will undoubtedly increase from upgrading the existing system and will cause further issues in the future.
A problem that often arises from upgrading existing systems is that the original documentation doesn't provide sufficient information to allow code additions to be made easily. When this happens the developers are left with two main options to proceed when needing to edit the original system: reengineering, and backwards-engineering. Either of these methods when employed take time and engineering resources that could have been better spent elsewhere.
The first of these methods is to create a requirements document based on the original system and relies on the developers understanding the existing system and what the requirements of it were. The second of these requires the developers to better understand the system in order to produce code that works in the same way. Both of these techniques are described in more detail later in this article.
The problem of not knowing enough about the system is also a concern expressed by software engineering expert, Ian Sommerville:
It is unusual for any one person to have complete understanding of the system. [Som01]
Years of accumulated code changes lead to less maintainable code [Sea03]
What Sommerville means by this is that after so many people have worked on the system over time that it has strayed so far from the original specification that no one person will have the full knowledge of how the system works and how modifications can be made. This same point becomes apparent in the views of many software engineers, and can also be seen as a point made by Robert Seacord (who wrote a paper on this back in 2003).
As mentioned earlier, the company in question would have had work done by at least one programming house that had been brought in, and also patches made to it by their in-house maintenance team. In this situation it is likely that poor documentation would have been available on how the system works and how it could be modified to introduce new upgrades. Since some sort of interface would need to be made to both the existing servers there must be some way for information to be accessed from these which could be as simple as just using existing methods or typically some ad-hoc interface would be implemented as was done before. A possibly better solution to this would be to actually rework the interfaces to modern standards, or possibly even to rewrite the system from scratch based on the existing one - though for this the cost must be weighed against the future benefits in order to determine which would be the best method to take.
