This post is the second series of Legacy System. The first part of this series is about The definition of Legacy System. Now, we are looking deeply into some characteristics of Legacy System. Keep in mind that this part is a part of my master research in University of Utrecht.
In his paper, Sneed (2006) divided legacy programs into three basic categories in regard to the degree of dependence on their environment. Those are as followed:
• Programs which are not dependent on their environment,
• Programs which are partially dependent on their environment,
• Programs which are totally dependent on their environment.
He also provides the examples of programming language which fall into each category. The programming languages that fall into first category are Fortran, Cobol and C/C++, while the second category are PL/I, Smalltalk, and Forte. The programming languages in the third category consist of 4th generation language programs, such as ADSOnline, Natural, CSP and Oracle Frames.
Juric et al. (2000) divided legacy system into 2 parts: (i) traditional, and (ii) modern system. Traditional means that the system is mostly mainframe based system, while modern means that system written in modern language such as C, C++, etc. Zhang, Liu, & Yang (2005) also have the same perception about legacy systems. They argued in their paper that legacy system can be characterized as a monolithic, single-tier and mainframe-based application.
Another characteristic of legacy systems is the way it was built. Legacy systems tend to have un-integrated (stovepipe) and monolithic architecture that make them unwieldy and rigid. Weiderman et al. (1997) explained in their paper that un-integrated (stovepipe) software assets that are not used for continuous production of additional assets become stale and require increasingly assets to maintain them. Eventually, there may be more cost associated with their continued maintenance than benefit from their continued use.
However, this traditional architecture at some point has reached its limitation. From technical aspect, the technical architecture of legacy system is obsolete (Colosimo et al., 2007). Thus, they are inflexible to the new changes and do not responsive enough to meet new business requirements. For instance, changing in structure of the organizations, such as corporate mergers or acquisition can easily disrupt legacy system (Weiderman et al, 1997). Moreover, the limitation also comes from incompatibility to meet the expectation for the use of modern technologies (e.g. modern user interface) (NASCIO, 2008).
One main point about legacy systems is that they are typically forming the backbone of information flow and cannot simply be discarded (Aversano & Tortorella, 2004). They hold detailed business rules and play a crucial role in organization’s business operations for long period of time. Therefore, these systems are typically mission-critical of the organization and failure of the systems can result serious impact on business. It makes makes legacy systems to operate 24 hours a day in order to keep their business process alive (Wu et al., 1997; Colosimo et al., 2007; Bisbal et al., 1999; and Paradauskas & Laurikaitis, 2006).
Last but not the least, legacy systems due to their age have been changed/evolved many times resulting in complicated system. As they were e, the performance is becoming slower and slower (Bisbal et al., 1999). Moreover, the structure and logic of legacy programs is strongly tied to the legacy data access logic makes legacy system more complex (Rahgozar & Oroumchian, 2002). As a consequence, they resist to modification and evolution to meet the new and constantly changing business requirements (Paradauskas & Laurikaitis, 2006).