|This article needs additional citations for verification. (March 2009)|
In computing a legacy system is an old method, technology, computer system, or application program,"of, relating to, or being a previous or outdated computer system." A more recent definition says that "a legacy system is any corporate computer system that isn't Internet-dependent." The term "legacy" may also have little to do with the size or age of the system — mainframes run 64-bit Linux and Java alongside 1960s vintage code.
Although the term is most commonly used to describe computers and software, use of the word legacy as an adjective may also describe human behaviors, methods, and tools. For example, timber framing using wattle and daub is a legacy building construction method.
The first use of the term legacy to describe computer systems probably occurred in the 1970s. By the 1980s it was commonly used to refer to existing computer systems to distinguish them from the design and implementation of new systems. Legacy was often heard during a conversion process, for example, when moving data from the legacy system to a new database.
The legacy system may or may not remain in use. For a variety of reasons, a legacy system may continue to be used. It may be that the system still provides for the users' needs, even though newer technology or more efficient methods of performing a task are now available. The decision to keep an old system may be influenced by economic reasons such as return on investment challenges or vendor lock-in, the inherent challenges of change management, or a variety of other reasons other than functionality.
Even if it is no longer used, it may continue to impact the organization due to its historical role. Historic data may not have been converted into the new system format and may exist within the new system with the use of a customized schema crosswalk, or may exist only in a data warehouse. In either case, the effect on business intelligence and operational reporting can be significant. A legacy system may include procedures or terminology which are no longer relevant in the current context, and may hinder or confuse understanding of the methods or technologies used.
Organizations can have compelling reasons for keeping a legacy system, such as:
- The system works satisfactorily, and the owner sees no reason to change it.
- The costs of redesigning or replacing the system are prohibitive because it is large, monolithic, and/or complex.
- Retraining on a new system would be costly in lost time and money, compared to the anticipated appreciable benefits of replacing it (which may be zero).
- The system requires near-constant availability, so it cannot be taken out of service, and the cost of designing a new system with a similar availability level is high. Examples include systems to handle customers' accounts in banks, computer reservation systems, air traffic control, energy distribution (power grids), nuclear power plants, military defense installations, and systems such as the TOPS database.
- The way that the system works is not well understood. Such a situation can occur when the designers of the system have left the organization, and the system has either not been fully documented or documentation has been lost.
- The user expects that the system can easily be replaced when this becomes necessary.
NASA's now retired Space Shuttle program used a large amount of 1970s-era technology. Replacement was cost-prohibitive because of the expensive requirement for flight certification; the legacy hardware used completed the expensive integration and certification requirement for flight, but any new equipment would have had to go through that entire process – requiring extensive tests of the new components in their new configurations – before a single unit could be used in the Space Shuttle program. This would have made any new system that started the certification process a de facto legacy system by the time of completion.
Additionally, because the entire Space Shuttle system, including ground and launch vehicle assets, was designed to work together as a closed system, and the specifications did not change, all of the certified systems and components served well in the roles for which they were designed. It was advantageous for NASA – even before the Shuttle was scheduled to be retired in 2010 – to keep using many pieces of 1970s technology rather than to upgrade those systems.
|This section does not cite any references or sources. (January 2008)|
Legacy systems are considered to be potentially problematic by some software engineers for several reasons (for example, see Bisbal et al., 1999).
- Legacy systems often run on obsolete (and usually slow) hardware, and spare parts for such computers may become increasingly difficult to obtain.
- If legacy software runs on only antiquated hardware, the cost of maintaining the system may eventually outweigh the cost of replacing both the software and hardware unless some form of emulation or backward compatibility allows the software to run on new hardware.
- These systems can be hard to maintain, improve, and expand because there is a general lack of understanding of the system; the staff who were experts on it have retired or forgotten what they knew about it, and staff who entered the field after it became "legacy" never learned about it in the first place. This can be worsened by lack or loss of documentation. Comair airline company fired its CEO in 2004 due to the failure of an antiquated legacy crew scheduling system that ran into a limitation not known to anyone in the company.
- Legacy systems may have vulnerabilities in older operating systems or applications due to lack of security patches being available or applied. There can also be production configurations that cause security problems. These issues can put the legacy system at risk of being compromised by attackers or knowledgeable insiders.
- Integration with newer systems may also be difficult because new software may use completely different technologies. The kind of bridge hardware and software that becomes available for different technologies that are popular at the same time are often not developed for differing technologies in different times, because of the lack of a large demand for it and the lack of associated reward of a large market economies of scale, though some of this "glue" does get developed by vendors and enthusiasts of particular legacy technologies (often called "retrocomputing" communities).
Improvements on legacy software systems
Where it is impossible to replace legacy systems through the practice of application retirement, it is still possible to enhance (or "re-face") them. Most development often goes into adding new interfaces to a legacy system. The most prominent technique is to provide a Web-based interface to a terminal-based mainframe application. This may reduce staff productivity due to slower response times and slower mouse-based operator actions, yet it is often seen as an "upgrade", because the interface style is familiar to unskilled users and is easy for them to use. John McCormick discusses such strategies that involve middleware.
Printing improvements are problematic because legacy software systems often add no formatting instructions, or they use protocols that are not usable in modern PC/Windows printers. A print server can be used to intercept the data and translate it to a more modern code. Rich Text Format (RTF) or PostScript documents may be created in the legacy application and then interpreted at a PC before being printed.
Biometric security measures are difficult to implement on legacy systems. A workable solution is to use a telnet or http proxy server to sit between users and the mainframe to implement secure access to the legacy application.
The change being undertaken in some organizations is to switch to Automated Business Process (ABP) software which generates complete systems. These systems can then interface to the organizations' legacy systems and use them as data repositories. This approach can provide a number of significant benefits: the users are insulated from the inefficiencies of their legacy systems, and the changes can be incorporated quickly and easily in the ABP software .
The term legacy support is often used with reference to obsolete or legacy computer hardware, whether peripherals or core components. Operating systems with "legacy support" can detect and use legacy hardware.
It is also used as a verb for what vendors do for products in legacy mode – they "support", or provide software maintenance, for older products. A "legacy" product may have some advantage over a modern product, even if not one that causes a majority of the market to favor it over the newer offering. A product is only truly "obsolete" if it has an advantage to nobody – if no person making a rational decision would choose to acquire it new.
In some cases, "legacy mode" refers more specifically to backward compatibility.
The computer mainframe era saw many applications running in legacy mode. In the modern business computing environment, n-tier, or 3-tier architectures are more difficult to place into legacy mode as they include many components making up a single system. Government regulatory changes must also be considered in a system running in legacy mode.[clarification needed]
IT has borrowed the term brownfield from the building industry, where undeveloped land (and especially unpolluted land) is described as greenfield and previously developed land – which is often polluted and abandoned – is described as brownfield.
- A brownfield architecture is an IT network design that incorporates legacy systems.
- A brownfield deployment is an upgrade or addition to an existing IT network and uses some legacy components.
There is an alternate point of view — growing since the "Dot Com" bubble burst in 1999 — that legacy systems are simply computer systems that are both installed and working. In other words, the term is not pejorative, but the opposite. Bjarne Stroustrup, creator of the C++ language, addressed this issue succinctly:
"Legacy code" often differs from its suggested alternative by actually working and scaling.
IT analysts estimate that the cost of replacing business logic is about five times that of reuse, and that is not counting the risks involved in wholesale replacement. Ideally, businesses would never have to rewrite most core business logic; debits must equal credits — they always have, and they always will. New software may increase the risk of system failures and security breaches.
The IT industry is responding to these concerns. "Legacy modernization" and "legacy transformation" refer to the act of reusing and refactoring existing core business logic by providing new user interfaces (typically Web interfaces), sometimes through the use of techniques such as screen scraping and service-enabled access (e.g. through web services). These techniques allow organizations to understand their existing code assets (using discovery tools), provide new user and application interfaces to existing code, improve workflow, contain costs, minimize risk, and enjoy classic qualities of service (near 100% uptime, security, scalability, etc.).
The re-examination of attitudes toward legacy systems is also inviting more reflection on what makes legacy systems as durable as they are. Technologists are relearning that sound architecture, practiced up front, helps businesses avoid costly and risky rewrites in the first place. The most common legacy systems tend to be those which embraced well-known IT architectural principles, with careful planning and strict methodology during implementation. Poorly designed systems often don't last, both because they wear out and because their reliability or usability are low enough that no one is inclined to make an effort to extend their term of service when replacement is an option. Thus, many organizations are rediscovering the value of both their legacy systems themselves and those systems' philosophical underpinnings.
Legacy system is also used as a euphemism for an old body of code, working or not. The word "legacy" implies that the system is a thing of value, even if it provides more cost than benefit, and helps to justify not replacing or discarding it.
- Application retirement
- Data migration
- Legacy code
- Legacy encoding
- Legacy port
- Software archaeology
- Software brittleness
- Software entropy
- Stovepipe system
- "Merriam-Webster". Retrieved June 22, 2013.
- Stone, Arney (June 13, 2001). "Keeping Legacy Software Alive". Bloomberg Businessweek. Retrieved June 22, 2013.
- Stephanie Overby (2005-05-01). "Comair's Christmas Disaster: Bound To Fail - CIO.com - Business Technology Leadership". CIO.com. Retrieved 2012-04-29.
- Razermouse (2011-05-03). "The Danger of Legacy Systems". Mousesecurity.com. Retrieved 2012-04-29.
- Jun 02, 2000 (2000-06-02). "Mainframe-web middleware - John McCormick". Gcn.com. Retrieved 2012-04-29.
- "Definition of greenfield and brownfield deployment". Searchunifiedcommunications.techtarget.com. Retrieved 2012-04-29.
- "Tips and Tricks for Legacy Hardware" by Danny Budzinski, Control Design Magazine, January 2011
- "Failure of a relatively new crew scheduling system during Christmas" by Stephanie Overby, CIO Magazine, May 1, 2005
- "THE FAILURE OF THE DIGITAL COMPUTER" by Adam N. Rosenberg
- Bisbal, J., Lawless, D., Wu, B. & Grimson, J. (1999). Legacy Information Systems: Issues and Directions. IEEE Software, 16, 103-111.
- Jim McGee (2005-11-10). "Legacy Systems: Why History Matters". Enterprise Systems Journal.
- "The Danger of Legacy Systems" by Steve R. Smith, May 3, 2011
- "Modernize Your Legacy Software Applications" by ISHIR