Informally, a legacy system may be defined as technology or software application environments that may be replaced by newer or more modern technology, but because of prohibitive cost, lack of detailed knowledge and, in some instances, effectiveness within the current context, the system continues to function and provide services to the organization. The intellectual capital stored up in legacy systems often represents a significant organizational asset; therefore, the management of these long-term systems is critical to organizations as they are not easily replaced.
The concept of software evolution has been in existence for many years. For example, J.I. Schwartz said the following at the second North Atlantic Treaty Organization (NATO) Software Engineering Conference in 1969:
Managers must be willing to adapt as situations arise requiring changes in scope or technique. The basic system must, through such means as data description divorced from procedures, centralized data maintenance, and data-independent programming languages, be flexible enough to permit change and evolution without reprogramming. People must be flexible enough to tolerate rather drastic changes in direction.
Organizations have made significant capital investments in their underlying software systems, and the expectation is that they will see a return on these investments and, consequently, that software will be usable for a good number of years. The life span of software is variable, but there are numerous examples of large systems remaining in use for more than 10 years. In fact, many large software installations remain in use for more than 20 years (e.g., systems at insurance companies and banks).
The business drivers for legacy modernization are numerous and provide good incentive for organizations to embark on these projects.
Business drivers include:1
The reality is that although legacy systems possess numerous limitations, such as green-screen interfaces that lack the conveniences of modern applications (i.e., drop-down menus, instant help files, intuitive navigation), approximately 70 percent of today’s organizations’ core business systems are legacy applications that are still heavily relied on to provide mission-critical business functionality.2
It is common knowledge that organizations regularly replace outdated equipment and machinery with newer and more modern systems. This is not generally the case with software systems and, in particular, legacy systems. These types of projects may lead to significant risk, including:
Incomplete Legacy System SpecificationIn most instances the original documentation of the system has been lost or is not representative of the current version of the system. The implication of this lack of adequate documentation is manifested as:
Business Processes and Legacy Systems CodependencyIn most instances, the organizations’ business processes have evolved around the underlying legacy system implementation and would have been designed to work around or avoid any software weaknesses. The importance of the relationship between the business process and the system often becomes clear when projects are undertaken in an attempt to change a process without touching the supporting legacy system module. In these circumstances, the codependency condition has the potential for disruptions in production operations.
Undocumented and Embedded Business RulesImportant business rules may be embedded or hard-coded into the software and may not be documented elsewhere. A business rule is a constraint that applies to some business function; the implementation of new systems that break these constraints can result in unpredictable consequences for the business. Programmers come and go and business rules that have been codified over the years by multiple programmers are difficult to understand by an individual or group new to the system. In these circumstances even routine programming changes may expose organizations to unintended consequences that may give rise to financial impacts (third-party claims), reputational damage and even regulatory breaches.
New Software Development RiskSoftware development is an activity that has a significant amount of uncertainty that is usually manifested as possible risk materialization.3 The well-known Chaos Report by the Standish Group in 1994 indicated that 16 percent of software projects were successful; 53 percent were challenged as a result of cost overruns, budget overruns or content deficiencies; and 31 percent were cancelled. This risk is magnified for new software developments involving interaction with legacy systems. The absence of a fully documented environment, aging infrastructure and a lack of standards contribute to an increased possibility of project failure. While keeping such legacy systems in production avoids replacement risk, this has to be balanced against the rising costs of maintaining the aging system.
While recognizing the value of existing systems and the risk involved in their replacement, organizations are realizing the value of adopting a modernization strategy as opposed to replacement. A 2010 survey conducted by NASCIO identified legacy modernization as one of the top 10 activities that organizations were planning to carry out in 2011.4
Modernization involves more extensive system changes than regular maintenance and results in the preservation of significant portions of the legacy investment while at the same time executing activities such as:
Organizations recognize that a modernization of programs represents a viable approach to upgrading legacy environments when risky and pervasive changes are needed to address changing business requirements.5
Modernization is the preferred approach to system evolution when the legacy system provides significant business benefit, but the growing complexities associated with system maintenance results in overall increased risk for the organization. In the main, there are two broad approaches to legacy system modernization:
The decision to replace a system as opposed to ongoing maintenance or modernization is usually predicated on the inability to justify the cost of maintenance or modernization efforts against the cost of acquiring a new system. The decision to utilize replacement as the route to system evolution must be evaluated against the inherent implementation risk associated with new system developments, since the system being introduced typically is not as stable as the old system. Additionally, consideration must be given to risk associated with the implementation of a new technology unfamiliar to supporting personnel. Therefore, when deciding upon a plan of action, organizations must gain an appreciation of the potential risk and develop mitigating plans through the application of an appropriate risk framework (e.g., COBIT 5 or Risk IT) to feed into the final decision.
The question facing organizations that have decided to embark on a modernization program is how to achieve the necessary agility while maintaining operating effectiveness, especially in those circumstances where the legacy system resides on either a mainframe, AS/400/IBM i, OpenVMS/Unix or Windows client server-type platform.
Part two of this article, to be published in volume 2, 2013, will examine some of the techniques available to organizations as they embark on modernization projects and will discuss the questions surrounding:
1 Hyland Software, “The Trouble with Legacy Systems,” www.hyland.com/Documents/udi/WhitePaper/WP_Whitepaper-Insurance-Leg124.pdf2 Loma, Paehr Roger; “Legacy Modernization: Creating an Agile Enterprise,” November 20073 Boban, M. Pozgaj; H. Sertic; Strategies for Successful Software Development Risk Management, vol. 8, 2003, p. 77-914 NASCIO, “State CIO Priorities for 2011,” 2010, www.nascio.org/publications/documents/NASCIO-CIO%20Priorities%202011.pdf5 Microsoft, “The Business Value of Legacy Transformation,” July 2007
Kirk Henry is head of the information and communications technology (ICT) department at the Trinidad & Tobago Unit Trust Corporation, the largest mutual fund provider in the Caribbean region. Henry has extensive experience in ICT governance, strategic planning and application systems development. He is currently spearheading a legacy modernization program that is based on his postgraduate work at the University of the West Indies, St. Augustine campus. Henry can be reached at email@example.com.
Enjoying this article? To read the most current ISACA Journal articles, become a member or subscribe to the Journal.
The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.
Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.
© 2013 ISACA. All rights reserved.
Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.