Maintenance Problems Of Old Legacy Systems example essay topic

SOFTWARE MAINTENANCEAbstractA consequence of the widespread utilization 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 minimise d 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. Such systems are typically old and heavily modified from their original designs by years of maintenance, usually by many different people [Moor 00]. Although legacy systems are technically obsolete, having been written in assembly or early third generation languages such as COAL Fortran and Coral, they generally represent considerable investment, and maintain significant value to their users [Benn 95] [Brod 95]. 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" [Benn 95] [Bisb 99]. 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 utilization 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 [Bisb 99] [Lee 97]. 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 [Coyl 00]. 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 [Bisb 99] [Somm 01].

For example, various studies have shown such maintenance consumes between 50 and 70 percent of a budget for atypical organisation utilizing legacy systems [Lien 80] [Nose 90]. 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 how 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 [Benn 95]. 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 [Bisb 99]. 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 [Chad 97]. 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, 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 wider e-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 [Press 01]. At the same time, the internal code documentation is updated, thus improving the overall structure of the code, and making it easier to maintain inthe 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 [Grah 94]. Generally, Wrapping involves the isolation and encapsulation of existing data, programs, application systems and interfaces using thin code wrappers [Bisb 99] [Weid 97]. This makes the wrapped component available to other processes, sort of acting like a server [Labr 00].

By utilizing 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 [Labr 00]. 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 [Merl 95]. 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 [Bisb 99].

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 [Canf 00]. Such migrations tend to occur to client - server platforms [Butl 96]. 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 [Canf 00]. 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 [Brod 95]. 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 [Bisb 99] [Grah 94]. 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.

4 Conclusions As shown in this report, the problems associated with the continued usage of legacy systems are wide and far-reaching. However, the mission-critical nature of many of these systems generally means this type of software cannot be discontinued. It is the job of the Software Maintenance Manager to address such problems and issues that arise, as discussed in this report. This report has shown a number of tools and methods by which the problems of using legacy systems in today's business environment can be reduced. However, this is by no means a definitive work, and there is a clear need for further research into finding which methodology is best suited under given situations. In any case, the methodology used by an organisation my only work in the short term, as they may even cause more problems in the future by increasing the complexity of the legacy system.

This is perhaps most true with regard to the Wrapping option as discussed in section 2 of this report [Bisb 99]. Until such research becomes available, it is up to the individual company and maintenance manger to decide upon how to tackle the problems posed by legacy systems. At the very least, such organisations and staff should conduct maintenance with future maintenance in mind. Although this does not solve the problems, it certainly alleviates a major problem, namely the inaccurate documentation that causes much of the problem in the first place. 5.

Bibliography

Benn 95] K. Bennet 'Legacy Systems: Coping with Success', I Software, Jan 1995, Vol 12 No 1 [Bisb 99] J.
Bis bal, D. Lawless, B. Wu & J. Grim son, 'Legacy System Migration: A Brief Review of Problems, Solutions and Research Issues' Technical Report TCD-CS-1999-38, Computer Science Department, Trinity College Dublin, May 1999.
Extended version of 'Legacy Information Systems: Issues and Directions', published in I Software Sept / Oct 1999, Vol 16, No 5 [Brod 95] M.
Brodie & M. Stone baker, 'Migrating Legacy Systems: Gateways, Interfaces and the Incremental Approach', Morgan Kauffman, USA, 1995 [Butl 96] J.
G. Butler, 'Mainframe to Client - Server Migration: Strategic Planning Issues and Strategies', Computer Technology Research Corporation, Charleston, SC [Canf 00] G. Can fora, A. Cimitile, A De Lucia & G. Di Lucca, 'Decomposing Legacy Programs: A First Step Towards Migrating to Client-Server Platforms', The Journal of Systems and Software, 2000 Vol 54 [Chad 97] R.
Chad ha 'Integration of Web with Legacy Systems Through Java Applets and Distributed Objects', Workshop on Compositional System Architectures, December, 1997 [Coyl 00] F.
Coyle, 'Legacy Systems: Changing Perspectives', I Software March / April 2000, Vol 17 No 2 [Grah 94] I.
Graham, 'Migrating to Object Technology', Addison-Wesley, 1994 [Labr 00] A.
Labret 'Lasting Legacies', Technology Decisions, web June 2000 [Lee 97] & W.
Kim, 'A Knowledge Based Maintenance of Legacy Systems: METASOFT', Expert Systems With Applications, Vol 12 No 4, 1997, pp 483-496 [Lien 80] B.
P. Lentz & B.E. Swanson, 'Software Maintenance Management', Addison- Wesley, 1980 [Merl 95] E.
Merl, P-Y. Gagne, J.K. Girard, K Kontagiannis & P. Panangaden,' Re-Engineering User Interfaces' I Software Jan 1995, Vol 12 No 1 [Moor 00] M.
M. Moore, 'Using MORPH', web 2000 [Nose 90] J.
T. Nose, & P. Prashant 'Software Maintenance Management: The Change in the Last 10 Years', Journal of Software Maintenance, 1999, Vol 2 No 3 [Press 01] R.
S. Press nam, 'Software Engineering: A Practitioner's Approach " McGraw Hill, 2001 [Somm 01] Sommerville, 'Software Engineering', Addison - Wesley, 2001.
Weid 97] N. Weider man, L. Northrop, D. Smith, S. Tilley & K. Wall nau,' Implications of Distributed Object Technology for Re-engineering', Technical Report CMU / SEI-97-TR-005, Carnegie Mellon University, June 1997.