A consequence of the widespread utilisation of computer based technology over the past few decades has been the emergence of vast, highly complex computer systems whose content and structure are increasingly resistant to modification and change. However fallible such legacy systems remain, many are “mission-critical” whereby their failure may lead to the collapse of the business or industry in which they serve.
In such cases, it is ultimately not possible to decommission the system in question. The present report investigates the nature of such systems and examines why legacy systems cause problems to Software Maintenance Managers? This report also provides a brief overview as to how such problems can be minimised and controlled.
Keywords: Legacy systems, legacy system migration, mission critical systems, re-engineering, software wrapping, software evolution.
1. Introduction
The literature describes legacy systems in terms of being an existing software application that is predominately within the maintenance phase of its lifecycle. Such systems are typically old and heavily modified from their original designs by years of maintenance, usually by many different people [Moor00]. Although legacy systems are technically obsolete, having been written in assembly or early third generation languages such as COBAL Fortran and Coral, they generally represent considerable investment, and maintain significant value to their users [Benn95] [Brod95].
Legacy systems typically form the backbone of information flow within an organisation, and as such, are essential for the function of its business. Failure in these systems is likely to have serious consequences hence why legacy software is often considered of a “mission critical nature” [Benn95] [Bisb99].
As can be expected, systems of this nature pose a number of problems to the users, and to the Software Maintenance Manager responsible for the upkeep of the system. Such problems range from the cost of maintenance to the utilisation of obsolete skills and technologies. However, several solutions have been proposed and documented in the literature in response to, and to minimise, these problems. Generally, they are classified under four categories: maintenance, re-development, wrapping and migration [Bisb99] [Lee97].
Therefore, the remainder of this report is structured as follows. The next section addresses the problems posed by legacy systems. Section 3 describes, with reference to the above 4 categories, methods and techniques used to minimise these problems. The concluding section presents a summary of findings and briefly discusses possible future research directions.
2. Legacy Problems
Obsolete or not, a recent study in the usage of legacy systems, estimated that more than 100 billion lines of working legacy code exit within the framework of modern business and industry [Coyl00]. With much of this code found within systems of a “mission critical” nature, the very existence of such code perpetrates considerable problems to the person responsible for system maintenance.
2.1 Hardware Issues
These systems are likely to run on hardware that has now been superseded. Not only are they likely to be large and slow to operate, they are liable to be expensive to maintain. Such costs mainly stem from the obsolete nature of the system. With a high demand and relative low supply of necessary parts and qualified personnel, the actual cost of maintaining the hardware driving the legacy system is certainly a problem to which the person in charge of maintenance should be aware [Bisb99] [Somm01]. For example, various studies have shown such maintenance consumes between 50 and 70 percent of a budget for a typical organisation utilising legacy systems [Lien80] [Nose90].
2.2 Software Issues
The actual maintenance of the software is liable to be time consuming and expensive. Again, there is an issue of skill shortages resulting in similar problems as discussed in relation to hardware issues above. People tend not to learn languages that are used in legacy systems because they are essentially obsolete, therefore placing high demands on those individuals who are skilled in legacy languages.
Another maintenance issue concerns the often poor state of the software documentation which gives rise to a lack of understanding as to the internal workings of the system. As numerous system changes have been made over time, often by many different people, there is typically a degradation in system documentation.
Such changes may have occurred in an ad hoc fashion whereby they were not fully planned or documented. Therefore, without adequate documentation, maintenance is often achieved solely through the examination of the actual system code as it is the only reliable system related information [Benn95]. This act of searching the code to trace faults is time consuming and costly, and is certainly a major problem to whoever is accountable for system maintenance.
2.3 Expansion Issues
With the software and hardware constraints already mentioned comes another problem associated with legacy systems. Their design, structure and configuration mean they are very difficult, if not impossible to expand upon [Bisb99]. This raises the possibility that a legacy system could become overloaded, and work above its capacity. This will further reduce its ability to function properly, and will cause further problems to the individuals who maintain the system.
2.4 Clean Interface Issues
Another problem arising from the use of legacy systems concerns issues relating to system integration. One area that has seen tremendous growth, thus necessitating businesses integration with it, has been that of the Internet [Chad97]. The rapid growth of this area has brought about numerous business opportunities. However, the general lack of clean interfaces within legacy systems has hampered efforts for businesses to utilise this technology.
The lack of such clean interfaces raises clear issues for system maintenance. In order to increase the companies productivity, the legacy system will have to be changed so it can be “plugged into” the new technology.
3. Reducing Legacy System Problems
Figure 1 shows the methods, as given in the introduction, by which Software Maintenance Manager can minimise the problems as addressed in section 2 of this report. The diagram also illustrates a sliding scale with respect to amount of work, number of changes, and the risks they involve. For example, re-developing is the option that brings about the most amount of work, risk and changes to the original legacy system. The following section, will consider each of the options available in turn in with respect to the sliding scale presented above.
3.1 Maintenance
By this, we mean the actual maintenance of the system as its stands, without utilising the other methods discussed in this section as each one in turn could be considered an act of software maintenance. For example, Wrapping could be viewed as a maintenance activity, the same could be said of migrating the system. For this report, maintenance is considered the adjustment of the original system to make it function as intended, without altering the systems actual functionality. This can be achieved in a number of ways.
As discussed in section 2, the failure of programmers in providing adequate documentation during system modification causes many problems for later maintenance. Therefore, the Software Maintenance Manager must ensure that staff members fully complete adequate documentation for each and every change they make to the system. Although such actions will not be retroactive, they will enable people to understand what has been changed to a particular part of the system at a later date.
Such an activity could also take the format of document restructuring. In this case, the maintenance team conducts a system wide re-documentation that fills in the gaps left by the previous programmers. This, if done correctly will enable future maintenance programmers to understand the code, and therefore the system in general. Software Maintenance Managers could also utilise system-restructuring methodologies to help reduce the associated problems of legacy systems.
In this situation, the organisation or maintenance manger must decide to restructure the system code, the data or both. In doing so, it is hoped the restructured system will have the same function as the original, but will perform at a higher level [Press01]. At the same time, the internal code documentation is updated, thus improving the overall structure of the code, and making it easier to maintain in the future.
3.2 Wrapping Legacy Systems
For many people conducting such maintenance, the total re-development of a given legacy system may not be an option. Such an operation is both time consuming, risky and costly. One option available is what is known as Wrapping [Grah94]. Generally, Wrapping involves the isolation and encapsulation of existing data, programs, application systems and interfaces using thin code wrappers [Bisb99] [Weid97].
This makes the wrapped component available to other processes, sort of acting like a server [Labr00]. By utilising Wrapping methodology, trusted components can be re-used and thus not negating the investment already put into marinating the original legacy system. The end result is a system that is more flexible, maintains original system integrity and does not necessitate the conversion of the entire system [Labr00].
One of the most popular implementations of Wrapping is Screen Scraping. Here, a Graphical User Interface (GUI) replaces a character based front end of the legacy system. The GUI enables data from the legacy system to be transported onto the desktop, and can be manipulated by the user [Merl95].
Although using such methods does reduce the problems associated with legacy systems, they are generally only short-term solutions. They tend not to address key problem areas such as their inability to evolve. Wrapping may also, in some cases, increase maintenance problems by the very fact that such a layer will also itself have to be maintained [Bisb99].
3.3 Migration
Often used when re-development is too risky and when Wrapping does not provide an adequate solution. In essence, legacy system migration is to move a existing operational system, to a new platform, while at the same time retaining its original functionality while causing as little disruption to the business as possible [Canf00]. Such migrations tend to occur to client – server platforms [Butl96]. Although a highly risky business venture that has attracted considerable empirical research over the past few years, migrating a legacy system has a number of potential benefits that reduce, or even eliminate problems associated with legacy systems [Canf00].
Perhaps the greatest advantages are concerning the reduction of support costs in maintaining the system. A successful migration removes the associated problems of the old legacy systems. After migration, the organisation and the people who will maintain the system have band new and complete system documentation.
This should therefore reduce the time and cost of future maintenance. The new system should also enable greater flexibility and ease of use for the end user. Not only will the migrated system be able to expand as the organisation grows, it is also liable to be more user friendly with the addition of GUI’s or other devices that generally improve human computer interaction. A migrated system is also liable to be more stable, and thus the actual amount of maintenance required should be reduced accordingly.
However, while a successful migration will benefit the organisation by reducing the problems associated with legacy systems, a failed migration is liable to cause the organisation many problems. Therefore, before such an action is taken, the organisation must have taken the necessary planning and preparation.
3.5 Re-development
Often called the Cold Turkey or Big Bang approach to system change and development [Brod95]. This method eliminates the maintenance problems of old legacy systems by re-developing them from scratch using modern design methods before running the system on a new hardware platform. It also enables the system to be designed with maintenance in mind, thus providing better economies of scale for those companies who choose to re-develop their systems. Obviously, such a re-development work is a mammoth undertaking and the literature generally asserts it to be risky to be utilised within the business environment [Bisb99] [Grah94].
Re-development projects face a real issue of failure. Quite simply, the new developed system may fail to work correctly and thus effect the business operation it was meant to help. Such failures may actually increase system maintenance demands and thus increase overall costs to the end user. Another problem of re-development stems from the evolution of computer technology and the business environment. As both areas are in constant change and flux, it is possible that a newly re-developed system no longer meets the need of the business. It is also possible that upon the time of completion, the technology used is itself considered obsolete.
