A legacy system is an old computer system or application program that continues to be used because the user (typically an organization) does not want to replace or redesign it.

Contents

Overview

 This section does not cite any references or sources.
Please help improve this section by adding citations to reliable sources. Unverifiable material may be challenged and removed. (January 2008)

Legacy systems are considered to be potentially problematic by many software engineers (for example, see Bisbal et al., 1999) for several reasons. Legacy systems often run on obsolete (and usually slow) hardware, and sometimes spare parts for such computers become increasingly difficult to obtain. These systems are often 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. 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).

Despite these problems, organizations can have compelling reasons for keeping a legacy system, such as:

  • The costs of redesigning the system are prohibitive because it is large, monolithic, and/or complex.
  • The system requires close to 100% availability, so it cannot be taken out of service, and the cost of designing a new system with a similar availability level is high.
  • The way 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 such documentation has been lost.
  • The user expects that the system can easily be replaced when this becomes necessary.
  • The system works satisfactorily, and the owner sees no reason for changing it; or in other words, re-learning a new system would have a prohibitive attendant cost in lost time and money, compared to the anticipated appreciable benefits of replacing it (which may be zero).

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. However, many of these systems do still meet the basic needs of the organization. The systems to handle customers' accounts in banks are one example. Therefore the organization cannot afford to stop them and yet some cannot afford to update them.

A demand of extremely high availability is commonly the case in computer reservation systems, air traffic control, energy distribution (power grids), nuclear power plants, military defense installations, and other systems critical to safety, security, traffic throughput, and/or economic profits. For example, see the TOPS database system.

NASA's Space Shuttle program still uses a large amount of 1970s-era technology for a reason which is a variant of the first: the systems may not be especially large, monolithic, or complex, but replacement is still cost-prohibitive because of the expensive requirement for flight certification; the legacy hardware currently being used has completed the expensive integration and certification requirement for flight, but any new equipment would have 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. Additionally, a weaker form of the fourth case applies: because the entire Space Shuttle system, including ground and launch vehicle assets, was designed to work together as a closed system, and the specifications have not changed, all of the certified systems and components still serve well in the roles for which they were designed, though there is an undesirable cost of maintaining these systems with now-rare parts, which provides some motivation to change them. Still, these two factors together mean that 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. NASA was working on many major projects to upgrade the Shuttle before the scheduled termination of the program, but they were safety upgrades and not technology modernization.

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.

Note that "legacy" has little to do with the size or even age of the system — mainframes run 64-bit Linux and Java, after all, right alongside 1960s vintage code.

Improvements on legacy software systems

Where it is impossible to replace legacy systems for reasons mentioned above, it is still possible to enhance 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. This is despite the fact that the users of such corporate systems usually require them to do their jobs and so typically use them often enough to become experts quickly. John McCormick discusses such strategies that involve middleware.[1]

Printing improvements are also 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.

Legacy support

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 obsolete or "legacy" products. A product is only truly "obsolete" if is has an advantage to nobody – if no person making a rational decision would choose to acquire it new – whereas a "legacy" product may have some advantage over a modern product, but not one that caused a majority of the market to favor it over the newer offering.

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]

Virtualization technology allows for a resurgence of modern software applications entering legacy mode. As system complexity and software costs increase, many computing users are keeping their current systems permanently in legacy mode.

Brownfield architecture

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.[2]

  • 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.

Alternative view

 The tone or style of this article may not be appropriate for Wikipedia. Specific concerns may be found on the talk page. See Wikipedia's guide to writing better articles for suggestions. (December 2007)

There is an alternate point of view — growing since the "Dot Com" bubble burst in 1999 — that legacy systems are simply (and only) computer systems that are both installed and working. In other words, the term is not at all pejorative — quite the opposite. Perhaps the term "legacy" is only an effort by computer industry salesmen to generate artificial churn in order to encourage purchase of unneeded technology. Bjarne Stroustrup, creator of the C++ language, addressed this issue succinctly:

"Legacy code" often differs from its suggested alternative by actually working and scaling.

—Bjarne Stroustrup

IT analysts estimate that the cost to replace business logic is about five times that of reuse, and that's not counting the risks involved in wholesale replacement. Shareholders and managers are increasingly asking, "Why are we spending so much money on new technology with so little to show for it?" Ideally businesses would never have to rewrite most core business logic. After all, debits must equal credits — they always have, and they always will. Businesses and governments are also recoiling at well-publicized system failures and security breaches that all too commonly arrive with new software — failures which are utterly catastrophic in many cases. (A regional airline fired its CEO due to the failure of an antiquated legacy crew scheduling system during Christmas, 2004, for example.[3]) There's also a growing backlash against large, packaged software products (SAP, Oracle, PeopleSoft, and others) which were oversold and in some cases have proven too costly, inflexible, and poorly matched to business needs.

Increasingly the IT industry is responding to these understandable business concerns. "Legacy modernization" and "legacy transformation" are now popular terms, and they mean 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 organisations 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.).[citation needed] Technology companies involved in "enterprise transformation" are growing and profiting by what many people feel is a more rational approach toward legacy systems.[citation needed]

The reexamination of attitudes toward legacy systems is also inviting more reflection on what makes legacy systems as durable as they are. Technologists are relearning the fact 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 not only the value in the legacy systems themselves but also their philosophical underpinnings.

See also

References

  1. ^ Mainframe-web middleware - John McCormick
  2. ^ Definition of greenfield and brownfield deployment
  3. ^ Comair's Christmas Disaster: Bound To Fail - CIO.com - Business Technology Leadership

Further reading

This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.

Retrieved from "http://en.wikipedia.org/wiki/Legacy_system"

No comments have been added.



Your name:

City:

Country:

Your comments:

Security check *
(Please enter the number into adjoining box)