Legacy Information Systems, Can They be Agile? A Framework for Assessing Agility

INTRODUCTION Organizations are frequently confronted with the dynamics of the environment in which they operate (Baker, 1996; Levine, 2005; Wadwha & Rao, 2003). Such dynamics can consist of organizational changes, changes required by law, market changes, and many more. The organizational processes that are influenced because of such changes need to be able to cope in order to operate effectively. Supporting these processes, information systems are often employed (Hill, Kraemer, & Gurbaxani, 2004; Ives & Learmonth, 1984; Wankadir, 2004). For instance, organizational and environmental changes may imply change in the supporting information systems. As found in available literature, this issue is fairly well known and has persisted over the years (Lehman, 1969; 1997). Organizations are often confronted with information systems that have been operational for years, have gone through many changes, and are based on older programming languages and paradigms (Staudenmayer et al., 1998). Such information systems are highly important for an organizations day-to-day business, but grow more difficult to maintain as time progresses. In this regard, Berghout and Nijland (2002) speak of the IT management paradox. Risk and uncertainty are the highest at the beginning of a project. The same goes for flexibility. These risks and uncertainties decrease as the project approaches completion. Unfortunately, the closer a project is to completion, the more difficult it is to adapt it to changing needs. This problem prolongs itself to the operational phase of information systems (after project completion). Operational information systems can be considered as complete, but are difficult to adapt to new circumstances. This problem of necessity for change in information systems has been identified from many different perspectives, such as development methods (Datta, 2006), programming paradigms (Van-Roy & Haridi, 2004), design principles (Martin, 2000), etc. Especially regarding the context of legacy information systems, this problem has been around for a long time and is one that mostly older organizations are confronted with (Bisbal, Lawless, & Grimson, 1999). This is largely due to their age (Parnas, 1994) and absence of knowledge within organizations regarding the information systems original design, the processes it supports (Bennett & Rajlich, 2000), and more. Aging information systems are often referred to as legacy (Chen & Rajlich, 2001). Therefore we adopt the following definition for legacy information systems: "any information system that significantly resists modification and evolution" (Brodie & Stonebraker, 1995). In order to effectively manage and thus maintain information systems, Looijen (2004) constructed an IT management framework. In this framework, three aspects of IT management are distinguished: functional (functionality), application and technical (infrastructure) management. Application management handles technical information system management (programming code, queries, etc.). A commonly applied framework in this regard, ASL2, speaks of the lifecycle of an application (Van der Pols, 2009). The main phases in this lifecycle are: planning, developing and exploiting. These phases tend to differ in length, although the exploiting phase generally generates the largest amount of costs (Berghout & Nijland, 2002). At the end of the exploiting phase is the end-of-life moment of an application. How does one decide when an information system has reached its end-of-life? In this paper we aim to achieve a better understanding of how to decide when an information system has reached its end-of-life. We propose that when an information system is no longer able to adequately respond to desired change, it has reached its end-of-life. Researchers have identified the ability to cope with change in different terms. Judging from their work, the different terms are highly context-dependent, and not for all of their definitions has a consensus been reached (Baker, 1996; Candea, 2008; Levine, 2005; Wadwha & Rao, 2003). …