SOFTWARE of vast, highly complex computersystems whose content

SOFTWARE of vast, highly complex computersystems whose content

SOFTWARE MAINTENANCEAbstractA consequence of the widespread utilisation of computer based technology overthe past few decades has been the emergence of vast, highly complex computersystems whose content and structure are increasingly resistant to modificationand change.

However fallible such legacy systems remain, many aremission-critical whereby their failure may lead to the collapse of thebusiness or industry in which they serve. In such cases, it is ultimately notpossible to decommission the system in question. The present reportinvestigates the nature of such systems and examines why legacy systems causeproblems to Software Maintenance Managers? This report also provides a briefoverview 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. IntroductionThe literature describes legacy systems in terms of being an existingsoftware application that is predominately within the maintenance phase of itslifecycle.

Such systems are typically old and heavily modified from theiroriginal designs by years of maintenance, usually by many different peopleMoor00. Although legacy systems are technically obsolete, having been writtenin assembly or early third generation languages such as COBAL Fortran and Coral,they generally represent considerable investment, and maintain significant valueto their users Benn95 Brod95.Legacy systems typically form the backbone of information flow within anorganisation, and as such, are essential for the function of its business. Failure in these systems is likely to have serious consequences hence why legacysoftware is often considered of a mission critical nature Benn95 Bisb99. As can be expected, systems of this nature pose a number of problems to theusers, and to the Software Maintenance Manager responsible for the upkeep of thesystem. Such problems range from the cost of maintenance to the utilisation ofobsolete skills and technologies. However, several solutions have been proposedand documented in the literature in response to, and to minimise, theseproblems.

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 nextsection addresses the problems posed by legacy systems. Section 3 describes,with reference to the above 4 categories, methods and techniques used tominimise these problems. The concluding section presents a summary of findingsand briefly discusses possible future research directions.2.

Legacy ProblemsObsolete or not, a recent study in the usage of legacy systems, estimatedthat more than 100 billion lines of working legacy code exit within theframework of modern business and industry Coyl00. With much of this codefound within systems of a mission critical nature, the very existence of suchcode perpetrates considerable problems to the person responsible for systemmaintenance.2.1 Hardware IssuesThese 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 beexpensive to maintain. Such costs mainly stem from the obsolete nature of thesystem. With a high demand and relative low supply of necessary parts andqualified personnel, the actual cost of maintaining the hardware driving thelegacy system is certainly a problem to which the person in charge ofmaintenance should be aware Bisb99 Somm01. For example, various studieshave shown such maintenance consumes between 50 and 70 percent of a budget for atypical organisation utilising legacy systems Lien80 Nose90.

2.2 Software IssuesThe actual maintenance of the software is liable to be time consuming andexpensive. Again, there is an issue of skill shortages resulting in similarproblems as discussed in relation to hardware issues above.

People tend not tolearn languages that are used in legacy systems because they are essentiallyobsolete, therefore placing high demands on those individuals who are skilled inlegacy languages.Another maintenance issue concerns the often poor state of the softwaredocumentation which gives rise to a lack of understanding as to the internalworkings of the system. As numerous system changes have been made over time,often by many different people, there is typically a degradation in systemdocumentation.

Such changes may have occurred in an ad hoc fashion whereby theywere not fully planned or documented. Therefore, without adequatedocumentation, maintenance is often achieved solely through the examination ofthe actual system code as it is the only reliable system related informationBenn95. This act of searching the code to trace faults is time consuming andcostly, and is certainly a major problem to whoever is accountable for systemmaintenance.2.3 Expansion IssuesWith the software and hardware constraints already mentioned comes anotherproblem associated with legacy systems. Their design, structure andconfiguration mean they are very difficult, if not impossible to expand uponBisb99.

This raises the possibility that a legacy system could becomeoverloaded, and work above its capacity. This will further reduce its abilityto function properly, and will cause further problems to the individuals whomaintain the system.2.4 Clean Interface IssuesAnother problem arising from the use of legacy systems concerns issuesrelating to system integration.

One area that has seen tremendous growth, thusnecessitating businesses integration with it, has been that of the InternetChad97. The rapid growth of this area has brought about numerous businessopportunities. However, the general lack of clean interfaces within legacysystems has hampered efforts for businesses to utilise this technology.The lack of such clean interfaces raises clear issues for systemmaintenance. In order to increase the companies productivity, the legacy systemwill have to be changed so it can be plugged into the new technology.3. Reducing Legacy System ProblemsFigure 1 shows the methods, as given in the introduction, by which SoftwareMaintenance Manager can minimise the problems as addressed in section 2 of thisreport.

The diagram also illustrates a sliding scale with respect to amount ofwork, number of changes, and the risks they involve. For example, re-developingis the option that brings about the most amount of work, risk and changes to theoriginal legacy system. The following section, will consider each of theoptions available in turn in with respect to the sliding scale presented above.3.1 MaintenanceBy this, we mean the actual maintenance of the system as its stands, withoututilising the other methods discussed in this section as each one in turn couldbe considered an act of software maintenance. For example, Wrapping could beviewed as a maintenance activity, the same could be said of migrating thesystem. For this report, maintenance is considered the adjustment of theoriginal system to make it function as intended, without altering the systemsactual functionality.

This can be achieved in a number of ways.As discussed in section 2, the failure of programmers in providing adequatedocumentation during system modification causes many problems for latermaintenance. Therefore, the Software Maintenance Manager must ensure that staffmembers fully complete adequate documentation for each and every change theymake to the system. Although such actions will not be retroactive, they willenable people to understand what has been changed to a particular part of thesystem at a later date. Such an activity could also take the format of documentrestructuring.

In this case, the maintenance team conducts a system widere-documentation that fills in the gaps left by the previous programmers. This,if done correctly will enable future maintenance programmers to understand thecode, and therefore the system in general. Software Maintenance Managers couldalso utilise system-restructuring methodologies to help reduce the associatedproblems of legacy systems.In this situation, the organisation or maintenance manger must decide torestructure the system code, the data or both.

In doing so, it is hoped therestructured system will have the same function as the original, but willperform at a higher level Press01. At the same time, the internal codedocumentation is updated, thus improving the overall structure of the code, andmaking it easier to maintain in the future.3.2 Wrapping Legacy SystemsFor many people conducting such maintenance, the total re-development of agiven legacy system may not be an option. Such an operation is both timeconsuming, risky and costly. One option available is what is known as WrappingGrah94. Generally, Wrapping involves the isolation and encapsulation ofexisting data, programs, application systems and interfaces using thin codewrappers Bisb99 Weid97.

This makes the wrapped component available to otherprocesses, sort of acting like a server Labr00. By utilising Wrappingmethodology, trusted components can be re-used and thus not negating theinvestment already put into marinating the original legacy system. The endresult is a system that is more flexible, maintains original system integrityand 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 ofthe legacy system. The GUI enables data from the legacy system to betransported onto the desktop, and can be manipulated by the user Merl95.Although using such methods does reduce the problems associated with legacysystems, they are generally only short-term solutions.

They tend not to addresskey problem areas such as their inability to evolve. Wrapping may also, in somecases, increase maintenance problems by the very fact that such a layer willalso itself have to be maintained Bisb99.3.

3 MigrationOften used when re-development is too risky and when Wrapping does notprovide an adequate solution. In essence, legacy system migration is to move aexisting operational system, to a new platform, while at the same time retainingits original functionality while causing as little disruption to the business aspossible Canf00. Such migrations tend to occur to client server platformsButl96.

Although a highly risky business venture that has attractedconsiderable empirical research over the past few years, migrating a legacysystem has a number of potential benefits that reduce, or even eliminateproblems associated with legacy systems Canf00.Perhaps the greatest advantages are concerning the reduction of supportcosts in maintaining the system. A successful migration removes the associatedproblems of the old legacy systems. After migration, the organisation and thepeople who will maintain the system have band new and complete systemdocumentation. This should therefore reduce the time and cost of futuremaintenance. The new system should also enable greater flexibility and ease ofuse for the end user. Not only will the migrated system be able to expand asthe organisation grows, it is also liable to be more user friendly with theaddition of GUIs or other devices that generally improve human computerinteraction.

A migrated system is also liable to be more stable, and thus theactual amount of maintenance required should be reduced accordingly.However, while a successful migration will benefit the organisation byreducing the problems associated with legacy systems, a failed migration isliable to cause the organisation many problems. Therefore, before such anaction is taken, the organisation must have taken the necessary planning andpreparation.3.

5 Re-developmentOften called the Cold Turkey or Big Bang approach to system change anddevelopment Brod95. This method eliminates the maintenance problems of oldlegacy systems by re-developing them from scratch using modern design methodsbefore running the system on a new hardware platform. It also enables thesystem to be designed with maintenance in mind, thus providing better economiesof scale for those companies who choose to re-develop their systems. Obviously,such a re-development work is a mammoth undertaking and the literature generallyasserts it to be risky to be utilised within the business environment Bisb99Grah94.

Re-development projects face a real issue of failure. Quite simply, the newdeveloped system may fail to work correctly and thus effect the businessoperation it was meant to help. Such failures may actually increase systemmaintenance demands and thus increase overall costs to the end user. Anotherproblem of re-development stems from the evolution of computer technology andthe business environment. As both areas are in constant change and flux, it ispossible that a newly re-developed system no longer meets the need of thebusiness. It is also possible that upon the time of completion, the technologyused is itself considered obsolete.

4 ConclusionsAs shown in this report, the problems associated with the continued usage oflegacy systems are wide and far-reaching. However, the mission-critical natureof many of these systems generally means this type of software cannot bediscontinued. It is the job of the Software Maintenance Manager to address suchproblems and issues that arise, as discussed in this report.

This report has shown a number of tools and methods by which the problems ofusing legacy systems in todays business environment can be reduced. However,this is by no means a definitive work, and there is a clear need for furtherresearch into finding which methodology is best suited under given situations. In any case, the methodology used by an organisation my only work in the shortterm, as they may even cause more problems in the future by increasing thecomplexity of the legacy system. This is perhaps most true with regard to theWrapping option as discussed in section 2 of this report Bisb99.Until such research becomes available, it is up to the individual companyand maintenance manger to decide upon how to tackle the problems posed by legacysystems. At the very least, such organisations and staff should conductmaintenance with future maintenance in mind.

Although this does not solve theproblems, it certainly alleviates a major problem, namely the inaccuratedocumentation that causes much of the problem in the first place.5. ReferencesBenn95K. Bennet “Legacy Systems: Coping with Success”, IEEE Software, Jan1995, Vol 12 No 1Bisb99J.

Bisbal, D. Lawless, B. Wu & J. Grimson, “Legacy System Migration: ABrief Review of Problems, Solutions and Research Issues” Technical ReportTCD-CS-1999-38, Computer Science Department, Trinity College Dublin, May 1999. Extended version of “Legacy Information Systems: Issues and Directions”,published in IEEE Software Sept/Oct 1999, Vol 16, No 5Brod95M.

Brodie & M. Stonebaker, “Migrating Legacy Systems: Gateways,Interfaces and the Incremental Approach”, Morgan Kauffman, USA, 1995Butl96J.G.

Butler, “Mainframe to Client – Server Migration: StrategicPlanning Issues and Strategies”, Computer Technology Research Corporation,Charleston, SCCanf00G. Canfora, A. Cimitile, A De Lucia & G. Di Lucca, “Decomposing LegacyPrograms: A First Step Towards Migrating to Client-Server Platforms”, TheJournal of Systems and Software, 2000 Vol 54Chad97R. Chadha “Integration of Web with Legacy Systems Through Java Appletsand Distributed Objects”, Workshop on Compositional System Architectures,December, 1997Coyl00F. Coyle, “Legacy Systems: Changing Perspectives”, IEEE SoftwareMarch/April 2000, Vol 17 No 2Grah94I. Graham, “Migrating to Object Technology”, Addison-Wesley, 1994Labr00A.

Labrot “Lasting Legacies”, Technology Decisions,http://www.technologydecisions.com/backissue/0600/08.

asp, June 2000Lee97 & W. Kim, “A Knowledge Based Maintenance of Legacy Systems:METASOFT”, Expert Systems With Applications, Vol 12 No 4, 1997, pp 483 496Lien80B.P. Lientz & B.E.

Swanson, “Software Maintenance Management”, Addison- Wesley, 1980Merl95E. Merlo, P-Y. Gagne, J.K. Girard, K Kontagiannis & P. Panangaden,”Re-Engineering User Interfaces” IEEE Software Jan 1995, Vol 12 No 1Moor00M.M.

Moore, “Using MORPH”,http://www.cis.gsu.edu/mmoore/MORPH/dissertation/approach.

html, 2000Nose90J.T. Nosek, & P.

Prashant “Software Maintenance Management: The Changein the Last 10 Years”, Journal of Software Maintenance, 1999, Vol 2 No 3Press01R.S. Pressnam, “Software Engineering: A Practitioner’s Approach”McGraw Hill, 2001Somm01Sommerville, “Software Engineering”, Addison – Wesley, 2001.Weid97N. Weiderman, L.

Northrop, D.Smith, S.Tilley & K. Wallnau,”Implications of Distributed Object Technology for Re-engineering”, TechnicalReport CMU/SEI-97-TR-005, Carnegie Mellon University, June 1997Words/ Pages : 2,388 / 24