Information SystemsMaintenance
Information Systems Maintenance: An Integrated Perspective
By: Chris Edwards Professor of Management Information Systems Cranfield School of Management Cranfield, England
Abstract This article argues that information systems maintenance is a morecomplexandintegrated task thanportrayed in the literature. It involvesnot only the maintenance of the applicationssoftware,but also all the other elementsin an operational system. The literature relating to the maintenance of eachelement is reviewedto reveal substantial underdevelopment in someareas andfragmentationbetweenelements.The presentpractice of focusing uponthe maintenance of particular individual elements is criticized anda new focus uponchangesin the information inputs to the systemsdevelopment processis proposed.Alternative methodsof managing the maintenance operation are examinedand the implications of these methodsin terms of designing the procedures, staffing the maintenance function, andthe needfor communication are discussed. Keywords:Informationsystemsmaintenance; systems life cycle; systemslife cycle management. ACMCategories:K.6.1
Introduction A great deal of academicand practical attention has been devoted to studying methods of developing computer-basedinformation systems; considerably less attention has been devotedto studying the managementof systems once implemented.The latter task is knownvariously as systemsmaintenance,applications maintenance, systems management, systems audit, postimplementation management,or applications management. Traditionally, the creation of information systems has beendiscussedby considering each task in a systemsdevelopmentcycle. In essence,that is a list of tasks requiredto be undertakenin the process of creating an information system. The developmentphasebegins the systemslife cycle whichtraces the life of a systemfrom inception to replacement. The latter part of the life cycle, namelysystemsoperation, is usually discussed by operationaltask with little referenceto anyparticular system.For instance,installation, security, file management,and engineering maintenance are usually discussed without reference to any particular operational system.Figure 1 showsthe matrix of operational tasks versus systems, highlighting the conventional discussion perspective. Not only is discussionorganizedin this way, but personnel are similarly allocated; analysts and programmers to system and operations personnel to tasks. Exceptin the largest installations offering very great development specilization, systems creation involves very few functional specializations whereassubsequent operation usually involves a greater number.Personnelinvolved in operations maywork on a numberof systems in one day, whereas development personnel maywork for manymonths on a single system. For this reason, operation demandsa greater degreeof functional integration. This article is concernedwith the processof ihtegration of elementsof operational systems:a global view of related post-implementation tasks is proposed which emphasizesthe systems rather than the functional perspective. The very early development of commercial systems tended to emphasize the problems of programming, since programming was very new and the business task to be developedwasusual-
MIS Quarterly/December 1984 237
Information SystemsMaintenance
ly well understood, logically structured, and essentially static. Systemsmaintenanceis now undergoing a similar evolutionary process: the emphasis is presently focused on maintaining software as against maintaining systems. This is not to say that software maintenanceis being overemphasized, merely that systems, maintenanceis being neglected. This article focuses upon centralized data processingorganizations, as the majority of applications presently existing are, andwill continueto be, processedin a centralized environmentfor a considerableperiod of time. However,the impact of distributed data processing upon systems maintenance will be’ briefly considered.
{:: .,.,
Systems Maintenance
O O
Development ~ Perspective (..g 0
Definitions of maintenancevary in a computerrelated context. Boehm[8] distinguishes between software update and software repair. The former involves enhancements whereasthe latter ensuresthat the programsperformas first intended. Ogdin [27] includes both of these under maintenancebut introduces the term modification to include changesthat result from a developing environment. Riggs [20] movestoward a wider view of maintenance in his definition: "Systemsmaintenanceis the activity associated with keeping operational computer systems continuously in tune with the requirementsof users, data processing operations, associated clerical functions, andexternal demandsfrom government and other agencies." Swanson’s [30] highly developedclassification of the demandsfor software maintenanceconsists of: A. Corrective Maintenancearising from: 1 Processingfailure to producedata. 2 Performancefailure to meet specified requirements. 3 Implementationfailure that has not yet led to 1 or 2 above.
Operational Tasks
238
MIS Quarterly~December1984
B. Adaptive maintenancearising from: 1 Changesin the data environment. 2 Changesin ’the processing environment
Information SystemsMaintenance
C2 The System
Application Software ~ A1 A2, A3, C1, C3.
B1
Environment
Figure 2 -- A Representation of Swanson’sDemands for Software Maintenance
involving hardwareor systemssoftware changes necessitating amendmentsto applications software. C. Perfective maintenancearising from: 1 Processing inefficiency of software which meets processing specifications yet can be improved. 2 Performance enhancement by amending, or addingreports, or facilities. 3 Maintainability improvementsto make programsmoreeasily maintainable. This classification can be representedin the form of Figure 2. Thesystemis seento consist of applications software and hardware, and to operate within a systems environment. Each of Swanson’s demandsfor maintenance is located in its orginating systems element and cross referencedwith the earlier list. Thearrowsshow
that wherever a demandarises the effect is to cause an amendment to the applications software. Changesin the data environment (B1) presumably occur either because0f changesin someother unspecified system elementor in the organizationalenvironment itself. Systems maintenance,as portrayedin this article, is considerably wider in scope than Swanson’s view of software maintenance. Figure 3 shows the operational system in the sameformat as Figure 2, but consisting of rather moreelements than Swanson’sincluded. Any element may require modification either becauseof an embodied existing error in that element (X), somechange occuring in someother element(Y), or somechangeoccuring in the environment (Z). A changein any element maydemanda consequentchangein itself (U), in some other element (V), or in the environment (W). Changes in one element can develop whole
MIS Quarter/y/December 1984 239
Information SystemsMaintenance
The Environment The System W
Applications Software Security Procedures X
V
The Database
Users
Figure 3 -- A Representation of Demands for SystemsMaintenance
240 MIS Quarterly~December1984
Information SystemsMaintenance
chains of required amendments involving numeroussystems elements.
organizational changesnecessaryto utilize the newly developed system.
Building uponthis, systemsmaintenance is defined here as "an alteration to any systemselement necessaryto eliminate a fault in that element, adapt to a changein that or any other element,or to improve uponthe performancecharacteristics of an element." In essence,this is merelyan expansion and generalization of Swanson’sclassification to allow for other systemelements. For example,A1, B2, and C2in Figure 2 are particular examplesof X, Y and Z in Figure 3, respectively However, this expansion in the scope of the definition changes the whole nature of the maintenancetask and, in particular, demandsa reconsideration of how the expanded requirementsmight be operationalized.
Eachtask can be classified either as a control task or as a productiontask. Control tasks direct the flow through the developmentcycle whereas production tasks develop elements of the required system. For example, task 1 is an investigation whichresults in a report whichis used in task 2. Henceboth task 1 and2 might be viewed as control tasks as together they direct the subsequentflow. Contrast this with task 10 which involves the production of software--an element in the operational system. Some tasks result in a statement of requirements which are then embodied in a numberof other systemselements. Suchtasks are still productionstasks. Thedevising of security specifications would be an exampleof such a task as the resulting controls are embodied in the software, the manualsystems, and possibly other elements. Usually a production task will result in someformof documentation that will survive for the entire life of the systemandbe updated as changesoccur.
SystemsLife Cycle The developmentlife cycle has been defined by manyauthors with only minor variations. Alternative task titles andthe level of detail envisaged by the individual authorsmakedifferent;es appear moresignificant than is actually the case. In essence,a development life cycle is a structured methodof producing the elements required for a system.For the purposesof this article, the life cycle is to consist of the tasks shownin Figure 4. This life cycle consists of 18 tasks whichcan be groupedinto four stages: SystemsOverview-- Tasks 1 and 2 involve investigating the nature of the problem and undertaking a brief appraisalas to its suitability for computerprocessing. SystemsDesign -- Tasks 3 through 6 demanda detailed consideration of user requirements and the proposal of a numberof outline solutions. Thelast task in this stage involves evaluating the alternatives and selecting an appropriateaction plan. SystemsCreation -- Tasks 7 through 1 5 are the core of the developmentprocess and involvea great deal of effort. This is the stagein whichthe majority of the elementsrequired to utilize the systemare created. Systems Implementation -- Tasks 16 through 18 focus on implementing the
Figure 5 recasts the development life cycle labeling eachtask as production(p) or control (c), showsthe resulting systemselements. Interactions between tasks and systems elements are indicated. An arrow pointing towarda systemselement(i.e., upwards)indicates that the task in that row results in the systemselementin that column. An arrow pointing towarda task (i.e., to the left) indicates that information fromthe elementin that columnis usedin the task. For example,the task of security designresults in a security specification whichis then used in the tasks of computer systems design and manual systems design. Systems elements of hardware and systems software are not included, as theseare essentially installation specific and are system dependent to a very limited extent. Thefigure doesnot attemptto portray iteration within tasks and betweentasks as this wouldconfusethe situation. Most of the systemsdevelopmenttasks draw information from the organization and its environment. Figure 6 showsthe relevant organizational information addedto Figure 5. An arrow pointing towardsa particular task portrays that the type of information specified by that columnis used in that task. For example, to adequately analyze
MIS Quarterly~December 1984 241
Information SystemsMaintenance
Systems Overview (1) Stage 1 Decision Point (2) stop Analysis and Verification of User Needs(3) General SystemsDesign (4) Stage 2 SystemsJustification 15) stop or Decision ~oint (6) redesign Security~l~esign(7) ComputerSyste.ms Design (8) anua Systems Design (9) Write and Test Programs(1 O) Stage 3 UserTraining (11 Computer Speciallity Training (12) ClerkTrair~ing(1 3) SystemsTesting (1 4) retest Decision.Point (1 5) DatabaseCreation I1 6)
,,mpemenation I1 7) !
Stage 4
PostI mp I ementationAudit (18) Figure 4 -- A SystemsDevelopmentCycle
user needs for information would require data relating to the business environment, the businessorganization, characteristics of users, and details of the task to be undertaken.Precise details of the information required is system-and organization-dependent. The developmentcycle can thus be seen as a structured set of proceduresfor gathering information relating to the organization and transforming this into the elements required for an operational system. Task 18, namely the post-implementation audit, is essentially a non-repetitive activity and hence information inputs for this task do not need to
242 MIS Quarterly~December 1984
be monitored other than immediately following implementation. Eachof the resulting systemselementshas a time dimension and may or may not need to be updatedas the original informationinputs to that elementchange.Figure 7 is a cross-reference of information inputs and the resulting systems elements. This has been compiled from Figure 6 by tracing systems elements through the development cycle to the information required for each element. Wheninformation directly relates to an elementit is shownin Figure 7 by an upward pointing arrow. The dots represent situations in
Information SystemsMaintenance
E
Production
(P)
or Control
Post-implementation Report
(C)
report
on systems
tes¢ing
justification Feasibility
report
Specification Systems
of user
specification
needs (overview
Justification Security
specification
Computer systems overview/prog. specs/database design Procedures
manual/forms
Software
& documentation
Trained
users
Trainer
computer
Trained
clerks
dept.
staff
Database
MIS Quarterly/December 1984 243
Information SystemsMaintenance
(I) SystemsOverview (2) DecisionPoint Analysisand Verification (3) of User Needs (4) GeneralSystemsDesign (5) Syste~ Justification (6) DecisionPoint (7) SecurityDesign (8) C~ter Systems. Design (9) ManualSystemsDesign (10) Write and Test Programs (II) User Training (12) O~ter Specialist Trs/ning (13) Clerk Training (14) SystemsTesting (15) DecisionPoint (16) D~tabaseCreation (17) Implementation Audit (18) Post-lmplement~tion Figure 6 Information Inputs to the Development Cycle and Resulting Elementsin the Operational System
244
MIS Quarterly~December1984
Information SystemsMaintenance
WOI~INGPAPF_/~
~,~fl~’gl~
IN OPEPATIC~AL SYST]~
(c) (c) (P) (P) (P): (C)
(c)i
(P)l
¢)
~c)
MIS Quarterly~December 1984 245
Information SystemsMaintenance
Figure 7 -- A Cross Referenceof Information Inputs Against Elements’in an Operational System
which an element draws information from a second elementand an information input is required for the latter, andthereforealso for the former. By consideringthis chart, oneis able to observethe effects of a changein information inputs upon systems elements. The systems developmentcycle can be seen as a structured procedurefor producing elementsin a systemgiven certain information inputs. A similar, if not identical, chart will needto exist to process changesto a system.Figure 7 portrays the situations in whichchangein an information input will demandchange in the cross-referenced ele-
246 MIS Quarterly/December 1984
ments.Notall informationinput changes will result in corresponding changes in cross-referenced elements.For example,changesin an installation policy might.not affect users, henceuser retraining maynot be necessary. However, every elementwill needto be consideredfor every change in a cross-referencedinformation input to checkif it is relevant. In summary,a systemconsists of elements which were produced as a consequenceof information gatheredat the development stage. It must follow that changes to this information may demand alterations to the system.
Information SystemsMaintenance
Surveyof the System Maintenance Literature This section will discuss the maintenance literature related to eachelementin an operational system. Often certain elements are combinedin the literature for discussionpurposes;this practice will be continuedhere. Secondly,this section will considerthe literature related to the organizational aspects of maintenance.
Specification of user needs Manyauthors have addressedthemselves to the problem of defining user needs. Manyconceptual and practical techniques have evolved to address this problem. Davis [8] reviews a number of methods of definition and classifies them as belongingto oneof the following strategies: asking, deriving from an existing system,synthesizing from characteristics of the utilization system, or discovering from experimentation with an evolving system.Thefirst three strategies might well be termed engineering approachesas they utilize the basic philosophyof engineers,namely to compile a completeand detailed specification of the task prior to commencingdevelopment. Theyare baseduponthe assumptionthat a set of requirements can be fully determined prior to detailed development The fourth method, knowngenerally as an evolutionary approach,recognizes the managerialproblemsinvolvedin report specification andinvolves iterations towarda final system.Interestingly, an ideal system that satisfies managers’needsis usually implied after which, presumably,systems maintenance personel update requirements. "Oncethe output system is shapedto accurately fit user requirements,an input systemis designed and developed," Berrisford and Wetherbe[2]. McCoshet. aL, [22] in a similar way, note that "once the prototype has served its experimental purpose, it will be replaced by a robust, viable system."Evolutionis usually not seenas a continuing process, but as a methodof defining user needs ultimately resulting in a defined set of requirementswhich will form the basis for a processing system. Researchrecognizing the continuing needto update user needs is not common.Edwards [11]
reports empirical investigations designedto determineorganizational variables that will encourage the continuing refinement of user needsthrough time. He envisagesthe maintenance of user needs to consist of amending the information providedto satisfy changingneedsof user managers,ceasing production of non-usedinformation, and encouraging usageof information perceivedas underutilized by the users’ superiors or the information’s producers. (The term producerswill be used here to denotestaff of the organizationalunit responsible for developingthe information systemandfor producingthe information.) Edwardsnotes that the organizations in which the maintenanceof user needs was operationalized all hadthe following characteristics: - resources clearly devotedto maintenanceof user needs, open user/producer communication channels, and - allocation of responsibility to motivatedpersonnel who perceived the maintenance of user needsas an important activity. The crudeness of this research can be seen in the implicit assumptionthat users knowwhat information they need. Suchan assumptionis also inherent in the evolutionary approachand usually implicit in distributed systemsdevelopment.This conflicts with the humaninformation processing literature summarizedby Davis [8] which suggests that managers either cannot identify or are unable to express their needs. Land[18], in synthesizingthe workof others, suggests approachesto dealing with changing user requirements. His systemsinclude considerable prethought of possible changes at the design stage, prototyping, and distributed systems development. Ramsgard[28] provides another view by suggesting that an inventory containingall the essential facts relating to all currently produced reports will reveal redundantand irrelevant reports and highlight unreasonable distribution lists. Further,it will exposeexecutives who receive too great a volumeof reports. The Comptroller General in the Standards for Audit of GovernmentOrganizations, Activities, and Functions [6] states that one of the general objectivesof audit workis" to ensurethat financial
MIS Quarterly~December 1984 247
Information SystemsMaintenance
SYSTEMS IMPLEMENTATION ANDINITIAL REVIEW
SYSTEMS DESIGN
Internal Audit Tasks ~’~ (Function B)
Verification of security controls (Function B)
t~
SYSTEMS OPERATION -- PERIOD1
Verification of security controls (Function B) Time
Figure 8 -- SystemsRelated Tasks ShownThroughTime
reports contain accurate, reliable, and useful financial data (emphasis added). This suggests _the needto inquire if the organizationis giving due consideration to identifying work (for example, producingreports) whichserveslittle or no useful purpose. Internal auditors appear to view themselvesas a checkingfunction to ascertain if the organization is monitoring changing needs, howeverthey suggest themselves as the secondary check, not the primary system.
Cost~valuespecification The comparisonof cost and value that is required prior to systemsdevelopment will differ in content significantly from that which is undertaken to justify systemsamendments. This, in turn, will significantly differ from the ongoingcomparison to ensurethat the value yielded is continuing to exceed cost. Without someform of communication, managers would not be aware of the cost. Hence, Bernard et al. [1 ] suggeststhat a systemof charging out cost to users would provide communication.This might encourageusers to comparecost with the value yielded and to discontinue those reports that did not justify the cost of production. Drury
248
MIS Quarterly~December 1984
[10] suggests that the existence of a charging system will encouageusers to be economical in using the system.Usersmight well havedifficulty in valuing a report, but mayfind it somewhat less demanding to decide if the value exceeds a stated cost. The selection of appropriate costing methodsis discussed in McKell [23]. The reoccurring costs of producinga report will formonly a small part of the total cost as projected in the initial systems appraisal. This occurs mostly becauseof the hidden nature of developmentcosts and the costs of databaseupdatesthat would not be significantly reducedif a single report were eliminated. The relevant ongoingcosts are a subset of those identified in the initial appraisaland, given that these are initially identified, can become the chargeout costs. Effectively, the cost/value justification is maintained to ensure value exceedscost through the life of the system. No literature waslocated that discussedorganizing chargeout systemsas part of a maintenance function.
Security specification Manyauthors addressthemselvesto the issue of designing systems that assure availability,
Information SystemsMaintenance
Monitoring Systems operation and amending as necessary (Function A)
Monitoring. Systems operation and amending as necessary (Function A)
SYSTEMS OPERATION -- PERIOD2
SYSTEMS OPERATION -- PERIOD3
’T Verification of security controls (Function B)
Verification of security .controls (Function B)
preserveconfidentiality, and provide information integrity: Thereis little discussionin the information systemsliterature relating to the methods by which these controls might be maintained in changingorganizational circumstances. The very detailed workby Martin [26] covers the issues in the area of designing secure systems. In 626 pages, Martin addresses 10 pages to this area andeven these relate only partly to the issue of maintenance. The issue of ongoing operations being reviewed on a functional basis is particularly relevant here. Issues such as protected areas, fire hazard, sabotage, electromagnetic radiation, and databaserecreation systemsare a small sample of the issues to be considered in a functional perspective. Auditors are becomingincreasingly involved in the data processingfunction. Evenso, manyaudit managersbelieve that they have only scratched the surface of computerauditing and do not have the personnelor audit tools they needfor effective operation. Macchiaverna[24], in a Conference Board Report, states that EDPauditing wasthe most frequently mentionedproblem area, receiving a mention by 16%of the 284 audit managerssurveyed.
Therole of the internal auditor in the maintenance of systemcontrols presents an important issue. Figure 8 represents the systems related tasks shownthrough time. Main et aL, [25] representing TheInstitute of Internal Auditors, see computer auditing as the verification of controls in three areas of the organization: applications, systemsdevelopment, and the information processing facility. Theysuggestthat the internal auditor performfunction B in Figure 8 (verifying that adequatesecurity controls exist), but that someone else should perform function A (monitoring the system and amendingthe controls as necessary). A ConferenceBoard Survey [24] showsthat 88%of internal auditors consider their role to include the reviewof data processing controls, but 70%also becomeinvolved in the development process to simplify subsequent auditing. Theyemphasizethe role of review as against (]esign to avoid compromisingthe checking function.
Noliterature waslocated that dealt with function A. Possibly producers who are pressured and overworkedhave been content to leave the task of identification of problem areas to internal auditors. With the increasing use of samplingon the part of auditors, this could be dangerous.
MIS Quarter/y/December 1984 249
Information SystemsMaintenance
Manualproceduresspecification The literature relating to the design of noncomputer aspects of computer systems (for instance, the design of forms) grew out of the organization and management literature with slight adaption for the differences involved in computer processing. The literature has not developedindependently. That which does exist is primarily concernedwith systemscreation virtually to the exclusion of maintenance,with repeated mention of the needfor regular reviews.
sideredin the literature. A surveyof data processing managersundertaken by Lientz and Swanson [19] identified inadequateuser training as oneof the six majorproblemareas in maintainingapplication systems. They suggest ongoing training as an important element of the maintenancefunction. Ramsgard [28] discusses the use of an inventory containing samples.of all reports as a training aid. He suggests that no new manager should be allowed to receive any computer reports until he has reviewedin detail the inventory of reports.
Database It is clearly importantthat data items andtransactions be added to, amended,and deleted from the database. It is of such importance and so clearly vital to operationsthat systemsare designed (at the developmentstage) to maintain the database. The ease of usageof such systemsis a major attraction to DBMS.The problems encounteredin adding data structures and changing the format of existing structures has been considered at length. However,such considerations seldom venture beyond the immediate systems - element and hence integration of elements is slight. Themajor exceptionto this is the security aspects incorporated into databasesystems. This is one of the few systemselementsin which maintenanceis designedinto the systemfrom the outset. As database managementsystems have developed, the implemention of changesboth to the data andto the structure of the databasehave easedconsiderably.
Training The training area has not changedsignificantly with the introduction of computer-basedsystems apart fromthe recent innovationof including training and assistance information within an application programto aid clerks and users alike. The content of training programs,moreoften than not, has focused on potential or existing systems analysts and programmers, although somedo focus uponuser managers.Suchtraining for user managersis often not organizationally centered nor systemsspecific. Seldomis the continuing availability of personnel trained in particular application systems con-
250 MIS Quarterly~December 1984
Specification and documentation This area of maintenance is of great practical importance and has attracted academicand professional attention because it is virtually unavoidable. Producers do not need to monitor users’ changing needs(users will inform the producer in no uncertain terms if the changesare important). Nor do producers need to evaluate systemssecurity (again, problemswill become very obvious or Internal Audit will inform the producerof any inadequacies). But producers do need to correct system that fails. Onemust consider, however, that corrective software maintenanceis usually regarded as a small part of the total software maintenance task (between 19 and 21%of the total software function [19, 20]). Other reasons for software maintenance-- perfective and adaPtive -- will also bedifficult to avoid.Userpressure for systems improvements can becomevery intense. In other cases, a new model of computer will demand software changesbefore it will process existing applications. Theliterature can be classified into four groupsor issues. Costof Maintenance -- A searchof the literature failed to locate studies that isolate the cost of systems maintenance as defined here, but a number of investigations highlight a subsetof this -- the cost of software maintenance[5, 13, 16, 17, 19, 29, 32, 33]. Tracing, Recording and Costing Software Amendments -- These range from very simple [34] to the more complex computer based systems [12] and are directed toward software maintenancecost analysis, [1, 32, 33], general
Information SystemsMaintenance
related statistics [27, 29, 30], and security aspects [31] of implementing changesto software. Motivation of Software MaintenanceStaff -Thebenefits accruing from integration or separation of maintenancefrom developmentforms the focus of attention. Improved ProgrammingTechniques to Ease the MaintenanceProblems-- The United State GeneralAccountingOffice [33] identified the improved use of tools andtechniques as the second most effective wayto reduce maintenancecosts. Ewers and Vessey [12] discuss 15 programmer productivity tools whichthey classify under the headings of: tools used in the programmingenvironment, tools used in the programcreation function, and program testing tools. They especially emphasizethe maintenancebenefits from such productivity tools. Donahue[9] uses over 1 O0pagesto extensively describe software maintenance tools andtechniquesin great detail. Discussions of software tools tend to be technical, andutilization often involves the purchase of particular software aids marketed by computermanufacturersand other large software producers.
systems when the demand for resources is reduced), and fixtures (who will stay with the system on a more or less permanent basis). Knowing from the outset that oneis to be involved in the maintenance of a system may well encourage one to develop adequate documentation. Freedmanand Wienberg [14] suggest adding maintenance staff to the post-implementation review committeeto achieve this sameobjective. Cooper[7] suggestsa variant of this wherebya permanently assigned program maintainer joins the developmentgroup to ease the transitional problems. Lientz and Swanson[19] report that separation of maintenance and development leads to increasedefficiency, although this was by no meansthe usual methodof organization noted. Other cases of alternative organizational methodscan be found [31 ].
Communication channels Systems maintenance depends on open communication channels between producers and users. A British ComputerSociety study [4] reveals user/producer communicationas an important problemarea. Edwards[11 ] confirms the importanceof.this aspect. Land[18] enumerates reasonsfor communication failures.
Resource requirements If producers are to play any significant role in maintenance,resourceswill be required. Lientz et al., [20] report that most senior managers regard software maintenanceas more important than developmentand hence, if the survey was representative, resources may well be made available for software maintenance. Glass and Noiseaux[15] profile a software maintainer which demands the qualities of a superman:flexibilty, broad background, patience, self motivation, responsibility, humility, innovation, and an historian. Authorsagreethat, in reality, the most inexperienced, the most inept, or the person mosteasily pressedinto service is often utilized.
Organizational design Tipshusand Sanderson[31 ] suggesta novel form of organization for software maintenance.They suggest creating a project teamfor development consisting of transients (whowill moveon to other
Discussion This article has attempted to showthat systems maintenanceshould involve all elements in an operational system. A review of the literature revealsa dearthof literature for the majorityof the elements of systems maintenance and a nearly total fragmentationinto non-interactingspecializations. This section offers positive direction in the maintenance dilemma by integrating proposals from manysources.
Whyis the presentsituation so unsatisfactory? Thequestionof whythis situation is presently unsatisfactory must be addressedbefore becoming involved in a consideration of action. Organizations spendthousands,if not millions of dollars developing computer-basedinformation systems
MIS Quarter/y/December 1984 251
Information SystemsMaintenance
with the intention that any individual systemwill last for a numberof years. Clearly, information support for the managerialtasks must have been important whenthe system was first developed and, unless a major change in organizational tasks androles has occurred, information support will still be of importance. As time passesand organizational changes occur, the system may yield progressively less value. The users, having becomefamiliar with the original system, will possibly be requiring systems enhancementsto increase the value yielded. Hence,the gap betweenthe value potentially and actually yielded becomeswider. Awaiting the obsolesence of a system before developing a replacement is unsatisfactory. For mostof the life of that system,it will not be providing the required information, and extremelysignificant problemscould occur by not keeping the system current. For example, breachesof security could occur resulting in the misplacement of millions of dollars. Liken this lack of maintenance to the purchase of any other organizational asset that depreciates, say a machine or a new building, and the need for systematic maintenance becomespatently obvious. A continually evolving system to meet changing organizational circumstances would appear preferable to a quickly degeneratingasset. In addition to these major points, the aggravation involved in users having to utilize an unsatisfactory system can hardly be productive. All of these commentsaddressing the need for maintenancehinge upon changeoccurring in the organization through time. Even though some systems in an otherwise changing organization might not be effected Lincoln [21] identifies a number of organizational and environmental pressuresthat wouldsuggestthat static organizations should be most uncommon.
Selecting a philosophy Figure 7, which cross references inputs to and outputs from the systems developmentprocess, is actually cross referencing two possible focuses of the maintenancefunction. First, a maintainer could adapt a reactive philosophy which involves awaiting demandsfor maintenanceand adjusting the system’s elements to satisfy the specified change.Sucha methodis effectively reacting to changes that becomeapparent. Programs would be amended if they fail, improvedif changesare
252 MIS Quarterly~December 1984
pressed by users, security procedures would be tightened after a failure becomes apparent, user training would be available uponrequest. Sucha system would be proportionately inexpensive to operate, but the value yielded by the systemmay also besimilarly small. An alternative philosophy, here termedproactive, would involve monitoring changesthat occur in the information inputs to the design processand, by using a chart of the form of Figure 7, tracing the effects of each input change upon the elementsin the system. Sucha systemwould, for instance, demandthe encumbentof a position to reappraise each report received for its utility whena particular organizationalposition is changed. Further, evenif a manager filling a position is not replaced, he will needto be monitoredto ensure that his needs, uponwhich the reports were designed, have not changed. A combinationof these two philosophiesis clearly possible, wherebycertain systemselements are considered on a reactive basis and others are monitored on a proactive basis. For instance, users might be monitored on a proactive basis whereassoftware might be-organized on a reactive basis. Selecting a maintenancephilosophy will depend primarily uponthe projected degreeof changein the environment of the system and the costs of alternative maintenancesystems. Such variables are difficult to quantify. Theprojected degreeof change and its projected effects can best be found by undertaking appraisal of each information input to the developmentprocess. Certain applications addresssingparticular tasks (for example, word processing) appear to require change less frequently than systems that are report specific (for example,order analysis reporting). The consequences of an ill-suited information system can vary widely. The cost of alternative systemsof maintenance,although not simple, is somewhat easier to appraise.
Whento consider maintenance Maintenance should be considered at the system’sdesign andcreation stages: it shouldnot be an afterthought. Either a separatetask in the development cycle titled ’design maintenance procedures’ is originated ora part of every
Information SystemsMaintenance
systems element should be devoted to maintenance. This is impossible for existing systems, but no further systems proposals should be drafted or acceptedwithout including a clear consideration of howeach elementis to be maintained. Systemsdesign of the maintenance function includes not only a discussionof whatis required to be performedbut also whois to do it andhowit is to be organized.
Allocating responsibility The design of maintenanceprocedures should be the responsibility of the system designer. Responsibility for the maintenancefunction can be performed by users, by producers, someby either, andsomeby both. As a starting point, it would seemreasonable to allocate the responsibility for each elementto the group that was responsiblefor producingit. This wouldimply that if systemanalysts weceinvolved in defining user needs, they would be continually involved in noting changesthat effect those needs. To turn responsibilty for maintenance over to users, as is implied whenauthors suggest ’signing off,’ requires that the users have learned a great deal from their participation in the developmentprocess. Further, it implies that they have the required degreeof overview of the whole systemto realize the implications of change.If sucha turnover of responsibility is envisaged, exhaustive user training will be needed.Lientz and Swanson [19] suggest that enhancements in terms of additional reports could be processedby users with the use of report generator languages whereas enhancements that demand changes to the databasewould be processedby producer staff. Whatever the division of responsibility, it is vital that someone has responsibility for the success of maintenance just as the leading systems analyst has in the developmentfunction.
Resourcerequirements There is a need for senior management to recognize the need for, and importance of, systems maintenancein order to allocate adequate resources. Previously discussed research suggeststhat senior managersdo recognize this need. The extension of these perceptions from software maintenance to systems maintenance
does not necessarily follow, although the logic underlying the importance of systems maintenancemight well encouragesupport.
Developing communicationchannels Systems maintenance depends on open communication channels between producers and users. Communication can be achievedin a variety of formal andinformal ways, but the methodof physically locating an analyst with a group of users to service a single systemappearsto meet the objectives of a close contact with users. Yet, in extremecases, this mayisolate analysts from producers.Manyother organizational possibilities exist to facilitate communication:for example, systems discussion groups, regular systems reviews,informal activities, andadvanced training sessions.
Theevolving role of the internal auditor Theinternal auditor has beenmentionedin relation to the maintenanceof various elements.The obviousextension of this responsibilty wassuggested by Lientz and Swanson[19] in their recommendation for life cycle audits. Theydid not contrast the roles of maintenanceas an ongoing task, andaudit as a final checkingfunction. Rather than being seen as a first line maintainer, the internal auditor shouldbe seenas the final check on efficient and effectiye operation by investigating all systemselements. To safeguardcompromising their position, auditors should not become associated with the systems maintenancefunction.
Attitude changes Tworelated, but apparently minor points might be valuable in securing effective systems maintenance. First, the title maintenance hardly engulfs the wider organizational tasks envisaged in this article. Sucha title suggests merelystriving to ensure that an initially given value persists. Systemsevolution, or somesimilar title, might move away from the narrow meaning of maintenance,towarda definition of striving to increase the value of the systemto the organization. A sec-
MIS Quarterly~December 1984 253
Information SystemsMaintenance
ond point involves changing the attitude of development staff to regard the new task of system evolution as equally important as system development.
Noiseux [15] include a discussion of six major points whyanalysts and programmers are not attracted to maintenance: maintenance is intellectually very difficult
Theeffects of distributed data processinguponthe maintenancefunctions A final point worthyof considerationis the effects of distributed processing upon the systems maintenancefunction. There are manyshadesof distribution rangingfromnear centralization of all systems elements to full user autonomy in creating and operating systems, The wide variety of situations that are labelled as distributed processing would lead to an extensive discussion of the effects of distributed data processing upon the maintenance activity. Such a discussion wouldnot be suitably presentedin this paper, but global comments might be appropriate. The control of elements by a single department headwill likely lead to an advantageous trade-off between benefits and costs. The benefits of systemsmaintenancein terms of improvedinformation will be knownto the operating department head, in addition to the costs. A choice as to resource allocation can be madebasedupon full information and with less political interference. The monitoring of either systemselements,or information input, will be considerably simpler to organizegiven it is the responsibility of a single person. The changesare occurring in the department in which the maintainer is employed, and hence the communication problem should be reduced.
Reasons for the Neglect of Maintenance One major question remains to be addressed: why, if systemsmaintenance is so important, is it so neglected in practice and academia? Consideringthe former, four points appearrelevant. Firstly, it is often noted that analysts and programmersprefer to be concerned with the development of new systems rather than the maintenance of existing systems. Glass and
254 MIS Quarterly~December1984
maintenance is technically very difficult maintenanceis unfair; necessaryinformation is not available; original program writers get promoted even though they leave a mess behind them maintenanceis no-win; people only come to maintenancewith problems maintenance work does not result in glory, noticeable progress, or chancesfor "success" maintenance li~es in the past, the quality of yesterday’s coding is often very poor Thesepoints combinedwith a world shortage of trained staff does not encouragesenior managers to insist on maintenance;computerstaff are all too mobile. Second,it maynot be in an analysts interests to addall of the very significant cost of maintenance into the cost/value proposalsfor risk of fewer projects being undertaken. The underestimation of maintenance cost in proposals makesit somewhat difficult to request additional staff once systemsare implemented.It is easier to severely limit the activity to that which is absolutely necessary. Any additional costs can be hidden either in the developmentof subsequentsystems or through the non-analysis of costs; a practice that thas beennoted [33]. Comparingprojected with actual maintenance costs would demanda sophisticated accounting system and even then manyreasons could be found for the huge difference. If, by chance, such information was available, an analyst would be even moretempted to do less maintenance. Third, Whena department experiences very high service demandswith a relatively fixed budget somethinghas to suffer: the usual attitude in manywalks of life is to select aspectswhich are least pressing from a short-term viewpoint and most difficult to measure.Systemsmaintenance, apart from software correction, appearsto be an obvious choice.
Information SystemsMaintenance
Lastly, maintenance has not been accepted historically as a major task. The author can rememberwhen,working as a junior programmer, a discussion centered upon the fate of the programmingstaff when all the organizations systems were fully programmed: viewing maintenance as a minor function is all too prevalent. To changesuch perceptions demands a major effort that maytake a considerableperiod of time. These foregoing arguments may suggest why maintenance is neglectedin practice but doesnot explain whythe area has receivedso little attention from academics. Apart from a very small number of noted people, research on the maintenanceissue has beenneglected. This applies, to a lesser extent, to all areas of MIS research. As in other areas of academia,there is a tendency to research where a body of knowledgealready exits (see, for instance, the MIS research developing out of cognitive psychology [34]). To be amongthe few working in an area is unfashionable and often leads to papers such as this where the discussion can _only suggestthe mosttentative of actions.
A cknowledgements Mythanks are offered to John Handleyfor many helpful comments offered on an earlier draft of this article.
References [1] Bernard, D., Emery,J.C., Nolan, R.L., and Scott, R.H. Charging for Computer Services: Principles and Guidelines, EDUCOM,1977. [2] Berrisford, T., andWetherbe,J. "Heuristic Development: A Redesign of Systems Design," MIS Quarterly, Volume3, Number 1, 1979, pp. 11-19. [3] Boehm, B.W. "Software Engineering," IEEE Transactions on Computers, C-25, December 1976, pp. 1226-1241. [4] British Computer Society, User Requirements in Data Processing, Heyden and Sons, London, England, 1979.
[5] Canning, R.G. (ed.)"That Maintenance Iceburg," EDP Analyzer, Number 10, 1972. [6] Comptroller General of the United States "Standards for Audit of Government Organizations, Programs,Activities, and Functions," Washington, DC, 1972. [7] Cooper, J.D. "Corporate Level Software Management,"IEEE Transactions on Software Engineering, SEo4, July 1978, pp. 319-325. [8] Davis, G.B. "Strategies for Information Requirements Determination," IBM Systems Journal, Volume21, Number1, 1982, pp. 4-30. [9] Donahue, J.D., and Swearinger, D. A Review of Software Maintenance Technology,ITT ResearchInstitute, Rome Air Defence Centre, RADC-TR-80-13, NewYork, NewYork, 1980. [10] Drury, D.H. "Conditions Effecting ChangebackEffectiveness," Information and Management, Number 5, 1982, pp. 31-36. [11] Edwards, C. "Determinants of Successful Information Systems Maintenance." Unpublished Ph.DDissertation, University of Strathclyde, Glasgow,Scotland, 1980. [12] Ewers, J. and Vassey, I. "The Systems Development Dilemma -- A Programming Perspective," MIS Quarterly, Volume5, Number2, June 1981, pp. 33-45. [13] Frank, W. The NewSoftware Economics, United States Professional Development Institute, Inc., Silver Springs, Maryland, 1979. [14] Freedman, D.P., and Weinberg, G.M. Guide to Walkthroughs, Inspections and Technical Reviews, Winthrop Publishers, Inc. 1982. [15] Glass, R.L., and Noiseux, R.A. Software Maintenance Guidebook, Prentice-Hall, Inc., EnglewoodCliffs, NewJersey, 1981. [16] Hoskyns Systems Research Centre, "Implications of Using ModularProgramming," Guide Number 1, John Hoskyns and Co Ltd, NewYork, NewYork, 1973. [17] Khan, Z. "How to Tackle the Systems Maintenance Dilemma," Canadian Data Systems, March 1975, pp. 30-32. [18] Land, F. "Adapting to ChangingUser Requirements," Information and Management, Number5, 1982, pp. 59-75.
MIS Quarterly~December1984 255
Information SystemsMaintenance
[19] Lientz, B.P., and Swanson,E.B. Software Maintenance Management, AddisonWesley Publishing, Reading, Massachusetts, 1980. [20] Lientz, B.P., Swanson, E.B., and Tompkins, G.E. "Characteristics of Application Software Maintenance," Communications of the ACM,Volume 21, Number6, 1978, pp. 266-471. [21] Lincoln, T.J. "Impact of the Changing Business Environment on Management and Their Information Needs," Management Datamatics, Volume 5, Number3, 1976, pp. 105-111. [22} McCosh,A.M., Rahman,M., and Earl, M.J. Developing Managerial Information Systems, John Wiley and Sons, NewYork, NewYork, 1981. [23] McKell, L.J., Hansen,J.V., and Heitger, L.E. "Charging for ComputingResources," ComputerSurveys, Volume11, Number2, 1979, pp. 105-120. [24] Macchiaverna, P. Internal Auditing, The Conference Board, NewYork, NewYork, 1978. [25] Mair, W.C., Wood,D.R., and Davis, K.W. ComputerControl and Audit, The Institute of Internal Auditors, Inc., Altamonte Springs, Florida, 1976. [26J Martin, J. Security, AccuracyandPrivacy in Computer Systems, Prentice-Hall, EnglewoodCliffs. NewJersey, 1 973. [27] Ogdin, J.L. "Designing Reli&ble Software," Datamation, Volume 18, July 1972, pp. 71-78. [28] Ramsguard, W.C. Making Systems Work, The Psychology of Business Systems, John Wiley and Sons, New York, New York, 1977. R. "Computer Systems [29] Riggs, Maintenance," Datamation, Volume 15, November 1969, pp. 227-235. [30] Swanson, E.B. "The Dimensions of Maintenance," Proceedings 2nd International Conference on Software Engineering, SanFrancisco, California, 13-15 October 1976, pp. 422-497. [31] Tipshus, E. and Sanderson, J. "Rotating ’Rival’ Programmers BetweenApplications and Maintenance DampensAntagonism, Improves Documentation," Data Management, Volume18, June 1 980, pp. 42-46. [32] Tompkins, G.E. "Characteristics of the
256 MIS Quarterly/December1984
High Cost of Maintenance," Unpublished Ph.D Dissertation, Graduate School of Management, University of California, Los Angeles,California, 1977. [33] United States General Accounting Office "Federal Agencies’ Maintenance of Computer Programs: Expensive and Undermanaged," AF MD-81-25, 1981. [34] Zmud,R.W. ’,Individual Differences and MIS Success: A Review of the Empirical Literature," Management Science, Volume 25, Number10, 1979, pp. 966-979.
Aboutthe Author Professor Chris Edwards(MA PhD FCMA)is Professor of Management Information Systemsat the Cranfield School of Management. He taught at the University of Strathclyde between19 73 and 1981. Fromthen until 1983 he wasresearching and teaching at the Carnegie-Mellon Graduate Schoolof Industrial Administration. ProfessorEdwards joined Cranfield School of Management in 1983. He is particularly interested in the organizational problems encountered by businesses using microcomputer-basedinformation systems. He is also involved in research related to the effectiveness of different types of information presentation, in particular the effective use of graphics.