Information Systems Maintenance: An Integrated …...For instance, installation, security, file management, and engineering maintenance are usually discussed without reference to any

Information Systems Maintenance

Information SystemsMaintenance: AnIntegrated Perspective

By: Chris EdwardsProfessor of Management

Information SystemsCranfield School of ManagementCranfield, England

AbstractThis article argues that information systemsmaintenance is a more complex and integrated taskthan portrayed in the literature. It involves not only themaintenance of the applications software, but also allthe other elements in an operational system. Theliterature relating to the maintenance of each element isreviewed to reveal substantial underdevelopment insome areas and fragmentation between elements. Thepresent practice of focusing upon the maintenance ofparticular individual elements is criticized and a newfocus upon changes in the information inputs to thesystems development process is proposed. Alternativemethods of managing the maintenance operation areexamined and the implications of these methods interms of designing the procedures, staffing themaintenance function, and the need for communicationare discussed.

Keywords:Information systems maintenance; systemslife cycle; systems life cycle management.

ACM Categories: K.6.1

IntroductionA great deal of academic and practical attentionhas been devoted to studying methods ofdeveloping computer-based information systems;considerably less attention has been devoted tostudying the management of systems once im-plemented. The latter task is known variously assystems maintenance, applications maintenance,systems management, systems audit, post-implementation management, or applicationsmanagement.

Traditionally, the creation of information systemshas been discussed by considering each task in asystems development cycle. In essence, that is alist of tasks required to be undertaken in the pro-cess of creating an information system. Thedevelopment phase begins the systems life cyclewhich traces the life of a system from inception toreplacement. The latter part of the life cycle,namely systems operation, is usually discussedby operational task with little reference to any par-ticular system. For instance, installation, security,file management, and engineering maintenanceare usually discussed without reference to anyparticular operational system. Figure 1 shows thematrix of operational tasks versus systems,highlighting the conventional discussionperspective.

Not only is discussion organized in this way, butpersonnel are similarly allocated; analysts andprogrammers to system and operations personnelto tasks. Except in the largest installations offer-ing very great development specilization,systems creation involves very few functionalspecializations whereas subsequent operationusually involves a greater number. Personnel in-volved in operations may work on a number ofsystems in one day, whereas development per-sonnel may work for many months on a singlesystem. For this reason, operation demands agreater degree of functional integration. This arti-cle is concerned with the process of ihtegration ofelements of operational systems: a global view ofrelated post-implementation tasks is proposedwhich emphasizes the systems rather than thefunctional perspective.

The very early development of commercialsystems tended to emphasize the problems ofprogramming, since programming was very newand the business task to be developed was usual-

MIS Quarterly/December 1984 237


{:: .,.,

O O

Development ~(.-

.g

0

Perspective

Operational Tasks

ly well understood, logically structured, andessentially static. Systems maintenance is nowundergoing a similar evolutionary process: theemphasis is presently focused on maintainingsoftware as against maintaining systems. This isnot to say that software maintenance is beingoveremphasized, merely that systems, main-tenance is being neglected.

This article focuses upon centralized data pro-cessing organizations, as the majority of applica-tions presently existing are, and will continue tobe, processed in a centralized environment for aconsiderable period of time. However, the impactof distributed data processing upon systemsmaintenance will be’ briefly considered.

Systems MaintenanceDefinitions of maintenance vary in a computer-related context. Boehm [8] distinguishes be-tween software update and software repair. Theformer involves enhancements whereas the latterensures that the programs perform as first intend-ed. Ogdin [27] includes both of these undermaintenance but introduces the term modificationto include changes that result from a developingenvironment. Riggs [20] moves toward a widerview of maintenance in his definition:

"Systems maintenance is the activityassociated with keeping operationalcomputer systems continuously intune with the requirements of users,data processing operations, asso-ciated clerical functions, and externaldemands from government and otheragencies."

Swanson’s [30] highly developed classification ofthe demands for software maintenance consistsof:

A. Corrective Maintenance arising from:1 Processing failure to produce data.2 Performance failure to meet specified

requirements.3 Implementation failure that has not yet

led to 1 or 2 above.

B. Adaptive maintenance arising from:1 Changes in the data environment.2 Changes in ’the processing environment

238 MIS Quarterly~December 1984


C2

The System

ApplicationSoftware

A1 A2, A3, C1, C3.~

B1

Environment

Figure 2 -- A Representation of Swanson’s Demands for Software Maintenance

involving hardware or systems softwarechanges necessitating amendments toapplications software.

C. Perfective maintenance arising from:1 Processing inefficiency of software

which meets processing specificationsyet can be improved.

2 Performance enhancement by amend-ing, or adding reports, or facilities.

3 Maintainability improvements to makeprograms more easily maintainable.

This classification can be represented in the formof Figure 2.

The system is seen to consist of applications soft-ware and hardware, and to operate within asystems environment. Each of Swanson’sdemands for maintenance is located in itsorginating systems element and crossreferenced with the earlier list. The arrows show

that wherever a demand arises the effect is tocause an amendment to the applications soft-ware. Changes in the data environment (B1)presumably occur either because 0f changes insome other unspecified system element or in theorganizational environment itself.

Systems maintenance, as portrayed in this article,is considerably wider in scope than Swanson’sview of software maintenance. Figure 3 showsthe operational system in the same format asFigure 2, but consisting of rather more elementsthan Swanson’s included.

Any element may require modification eitherbecause of an embodied existing error in that ele-ment (X), some change occuring in some otherelement (Y), or some change occuring in the en-vironment (Z). A change in any element may de-mand a consequent change in itself (U), in someother element (V), or in the environment (W).Changes in one element can develop whole

MIS Quarter/y/December 1984 239


TheEnvironment

W

ApplicationsSoftware

The System

TheDatabase

SecurityProcedures

V X

Users

Figure 3 -- A Representation of Demands for Systems Maintenance



chains of required amendments involvingnumerous systems elements.

Building upon this, systems maintenance is defin-ed here as "an alteration to any systems elementnecessary to eliminate a fault in that element,adapt to a change in that or any other element, orto improve upon the performance characteristicsof an element." In essence, this is merely an ex-pansion and generalization of Swanson’s classi-fication to allow for other system elements. Forexample, A1, B2, and C2 in Figure 2 are particularexamples of X, Y and Z in Figure 3, respectivelyHowever, this expansion in the scope of thedefinition changes the whole nature of themaintenance task and, in particular, demands areconsideration of how the expanded re-quirements might be operationalized.

Systems Life CycleThe development life cycle has been defined bymany authors with only minor variations. Alter-native task titles and the level of detail envisagedby the individual authors make different;es appearmore significant than is actually the case. Inessence, a development life cycle is a structuredmethod of producing the elements required for asystem. For the purposes of this article, the lifecycle is to consist of the tasks shown in Figure 4.

This life cycle consists of 18 tasks which can begrouped into four stages:

Systems Overview-- Tasks 1 and 2 involveinvestigating the nature of the problem andundertaking a brief appraisal as to its suitabilityfor computer processing.

Systems Design -- Tasks 3 through 6 de-mand a detailed consideration of user re-quirements and the proposal of a number ofoutline solutions. The last task in this stageinvolves evaluating the alternatives and selec-ting an appropriate action plan.

Systems Creation -- Tasks 7 through 1 5 arethe core of the development process and in-volve a great deal of effort. This is the stage inwhich the majority of the elements required toutilize the system are created.

Systems Implementation -- Tasks 16through 18 focus on implementing the

organizational changes necessary to utilize thenewly developed system.

Each task can be classified either as a controltask or as a production task. Control tasks directthe flow through the development cycle whereasproduction tasks develop elements of the re-quired system. For example, task 1 is an in-vestigation which results in a report which is usedin task 2. Hence both task 1 and 2 might be view-ed as control tasks as together they direct thesubsequent flow. Contrast this with task 10 whichinvolves the production of software--an elementin the operational system. Some tasks result in astatement of requirements which are then em-bodied in a number of other systems elements.Such tasks are still productions tasks. The devisingof security specifications would be an example ofsuch a task as the resulting controls are em-bodied in the software, the manual systems, andpossibly other elements. Usually a productiontask will result in some form of documentation thatwill survive for the entire life of the system and beupdated as changes occur.

Figure 5 recasts the development life cycle label-ing each task as production (p) or control (c), shows the resulting systems elements. Interac-tions between tasks and systems elements areindicated.

An arrow pointing toward a systems element (i.e.,upwards) indicates that the task in that row resultsin the systems element in that column. An arrowpointing toward a task (i.e., to the left) indicatesthat information from the element in that column isused in the task. For example, the task of securitydesign results in a security specification which isthen used in the tasks of computer systemsdesign and manual systems design. Systemselements of hardware and systems software arenot included, as these are essentially installationspecific and are system dependent to a verylimited extent. The figure does not attempt to por-tray iteration within tasks and between tasks asthis would confuse the situation.

Most of the systems development tasks draw in-formation from the organization and its environ-ment. Figure 6 shows the relevant organizationalinformation added to Figure 5. An arrow pointingtowards a particular task portrays that the type ofinformation specified by that column is used inthat task. For example, to adequately analyze

MIS Quarterly~December 1984 241


Systems Overview (1)

Decision Point (2)

Analysis and Verification of User Needs (3)

General Systems Design (4)

Systems Justification 15)

Decision ~oint (6)

Security ~l~esign (7)

Computer Syste.ms Design (8)

anua Systems Design (9)

Write and Test Programs (1 O)

User Training (11

Computer Speciallity Training (12)

Clerk Trair~ing (1 3)

Systems Testing (1 4)

Decision .Point (1 5)

Database Creation I1 6)

,,mp emen ation I1 7)!

P I Iost- mp ementation Audit (18)

Figure 4 -- A Systems Development Cycle

retest

stop

stop or

redesign

Stage 1

Stage 2

Stage 3

Stage 4

user needs for information would require datarelating to the business environment, thebusiness organization, characteristics of users,and details of the task to be undertaken. Precisedetails of the information required is system- andorganization-dependent. The development cyclecan thus be seen as a structured set of pro-cedures for gathering information relating to theorganization and transforming this into the ele-ments required for an operational system. Task18, namely the post-implementation audit, isessentially a non-repetitive activity and henceinformation inputs for this task do not need to

be monitored other than immediately followingimplementation.Each of the resulting systems elements has a timedimension and may or may not need to be up-dated as the original information inputs to that ele-ment change. Figure 7 is a cross-reference of in-formation inputs and the resulting systemselements. This has been compiled from Figure 6by tracing systems elements through thedevelopment cycle to the information required foreach element. When information directly relatesto an element it is shown in Figure 7 by an upwardpointing arrow. The dots represent situations in



Production (P) or Control (C)

Post-implementation report

Report on systems tes¢ing

justification

Feasibility report

Specification of user needs

Systems specification (overview

Justification

Security specification

Computer systems overview/prog.specs/database design

Procedures manual/forms

Software & documentation

Trained users

Trainer computer dept. staff

Trained clerks

Database

E

MIS Quarterly/December 1984 243


(I) Systems Overview

(2) Decision Point

Analysis and Verification(3) of User Needs

(4) General Systems Design

(5) Syste~ Justification

(6) Decision Point

(7) Security Design

(8) C~ter Systems. Design

(9) Manual Systems Design

(10) Write and Test Programs

(II) User Training

(12) O~ter Specialist Trs/ning

(13) Clerk Training

(14) Systems Testing

(15) Decision Point

(16) D~tabase Creation

(17) Implementation

(18) Post-lmplement~tion Audit

Figure 6Information Inputs to the Development Cycle and Resulting Elements in the Operational System



(c)

(c)

(P)

(P)(P):(C)

(c)i

(P)l

¢)

~c)

WOI~ING PAPF_/~ ~,~fl~’gl~ IN OPEPATIC~AL SYST]~



Figure 7 -- A Cross Reference of Information Inputs Against Elements ’in an Operational System

which an element draws information from a sec-ond element and an information input is requiredfor the latter, and therefore also for the former. Byconsidering this chart, one is able to observe theeffects of a change in information inputs uponsystems elements.

The systems development cycle can be seen as astructured procedure for producing elements in asystem given certain information inputs. A similar,if not identical, chart will need to exist to processchanges to a system. Figure 7 portrays the situa-tions in which change in an information input willdemand change in the cross-referenced ele-

ments. Not all information input changes will resultin corresponding changes in cross-referencedelements. For example, changes in an installationpolicy might.not affect users, hence user retrain-ing may not be necessary. However, every ele-ment will need to be considered for every changein a cross-referenced information input to check ifit is relevant.

In summary, a system consists of elements whichwere produced as a consequence of informationgathered at the development stage. It must followthat changes to this information may demandalterations to the system.

246 MIS Quarterly/December 1984


Survey of theSystem MaintenanceLiteratureThis section will discuss the maintenanceliterature related to each element in an operationalsystem. Often certain elements are combined inthe literature for discussion purposes; this prac-tice will be continued here. Secondly, this sectionwill consider the literature related to the organiza-tional aspects of maintenance.

Specification of user needs

Many authors have addressed themselves to theproblem of defining user needs. Many conceptualand practical techniques have evolved to addressthis problem. Davis [8] reviews a number ofmethods of definition and classifies them asbelonging to one of the following strategies: ask-ing, deriving from an existing system, synthesiz-ing from characteristics of the utilization system,or discovering from experimentation with anevolving system. The first three strategies mightwell be termed engineering approaches as theyutilize the basic philosophy of engineers, namelyto compile a complete and detailed specificationof the task prior to commencing development.They are based upon the assumption that a set ofrequirements can be fully determined prior todetailed development

The fourth method, known generally as an evolu-tionary approach, recognizes the managerial pro-blems involved in report specification and involvesiterations toward a final system. Interestingly, anideal system that satisfies managers’ needs isusually implied after which, presumably, systemsmaintenance personel update requirements."Once the output system is shaped to accuratelyfit user requirements, an input system is designedand developed," Berrisford and Wetherbe [2].McCosh et. aL, [22] in a similar way, note that"once the prototype has served its experimentalpurpose, it will be replaced by a robust, viablesystem." Evolution is usually not seen as a contin-uing process, but as a method of defining userneeds ultimately resulting in a defined set ofrequirements which will form the basis for a pro-cessing system.

Research recognizing the continuing need to up-date user needs is not common. Edwards [11]

reports empirical investigations designed to deter-mine organizational variables that will encouragethe continuing refinement of user needs throughtime. He envisages the maintenance of user needsto consist of amending the information provided tosatisfy changing needs of user managers, ceasingproduction of non-used information, and encourag-ing usage of information perceived as underutilizedby the users’ superiors or the information’s pro-ducers. (The term producers will be used here todenote staff of the organizational unit responsiblefor developing the information system and for pro-ducing the information.)

Edwards notes that the organizations in which themaintenance of user needs was operationalizedall had the following characteristics:

- resources clearly devoted to maintenance ofuser needs,

open user/producer communication chan-nels, and

- allocation of responsibility to motivated per-sonnel who perceived the maintenance ofuser needs as an important activity.

The crudeness of this research can be seen inthe implicit assumption that users know what in-formation they need. Such an assumption is alsoinherent in the evolutionary approach and usuallyimplicit in distributed systems development. Thisconflicts with the human information processingliterature summarized by Davis [8] which sug-gests that managers either cannot identify or areunable to express their needs.

Land [18], in synthesizing the work of others, sug-gests approaches to dealing with changing userrequirements. His systems include considerableprethought of possible changes at the designstage, prototyping, and distributed systemsdevelopment.

Ramsgard [28] provides another view by sug-gesting that an inventory containing all the essen-tial facts relating to all currently produced reportswill reveal redundant and irrelevant reports andhighlight unreasonable distribution lists. Further, itwill expose executives who receive too great avolume of reports.

The Comptroller General in the Standards forAudit of Government Organizations, Activities,and Functions [6] states that one of the generalobjectives of audit work is" to ensure that financial



SYSTEMS DESIGN

InternalAudit Tasks ~’~(Function B)

Verificationof securitycontrols(Function B)

SYSTEMSIMPLEMENTATION

AND INITIAL REVIEW t~SYSTEMS OPERATION-- PERIOD 1


Time

Figure 8 -- Systems Related Tasks Shown Through Time

reports contain accurate, reliable, and usefulfinancial data (emphasis added). This suggests_the need to inquire if the organization is giving dueconsideration to identifying work (for example,producing reports) which serves little or no usefulpurpose. Internal auditors appear to viewthemselves as a checking function to ascertain ifthe organization is monitoring changing needs,however they suggest themselves as the secon-dary check, not the primary system.

Cost~value specification

The comparison of cost and value that is requiredprior to systems development will differ in contentsignificantly from that which is undertaken tojustify systems amendments. This, in turn, willsignificantly differ from the ongoing comparison toensure that the value yielded is continuing to ex-ceed cost.

Without some form of communication, managerswould not be aware of the cost. Hence, Bernardet al. [1 ] suggests that a system of charging outcost to users would provide communication. Thismight encourage users to compare cost with thevalue yielded and to discontinue those reportsthat did not justify the cost of production. Drury

[10] suggests that the existence of a chargingsystem will encouage users to be economical inusing the system. Users might well have difficultyin valuing a report, but may find it somewhat lessdemanding to decide if the value exceeds astated cost.

The selection of appropriate costing methods isdiscussed in McKell [23]. The reoccurring costsof producing a report will form only a small part ofthe total cost as projected in the initial systemsappraisal. This occurs mostly because of the hid-den nature of development costs and the costs ofdatabase updates that would not be significantlyreduced if a single report were eliminated. Therelevant ongoing costs are a subset of those iden-tified in the initial appraisal and, given that theseare initially identified, can become the chargeoutcosts. Effectively, the cost/value justification ismaintained to ensure value exceeds cost throughthe life of the system.

No literature was located that discussed organiz-ing chargeout systems as part of a maintenancefunction.

Security specification

Many authors address themselves to the issue ofdesigning systems that assure availability,



Monitoring Systemsoperation andamending asnecessary(Function A)


SYSTEMS OPERATION-- PERIOD 2

Monitoring. Systemsoperation andamending asnecessary(Function A)

’TVerificationof security.controls(Function B)

SYSTEMS OPERATION-- PERIOD 3

preserve confidentiality, and provide informationintegrity: There is little discussion in the informa-tion systems literature relating to the methods bywhich these controls might be maintained inchanging organizational circumstances. The verydetailed work by Martin [26] covers the issues inthe area of designing secure systems. In 626pages, Martin addresses 10 pages to this areaand even these relate only partly to the issue ofmaintenance.

The issue of ongoing operations being reviewedon a functional basis is particularly relevant here.Issues such as protected areas, fire hazard,sabotage, electromagnetic radiation, anddatabase recreation systems are a small sampleof the issues to be considered in a functionalperspective.

Auditors are becoming increasingly involved inthe data processing function. Even so, many auditmanagers believe that they have only scratchedthe surface of computer auditing and do not havethe personnel or audit tools they need for effec-tive operation. Macchiaverna [24], in a Con-ference Board Report, states that EDP auditingwas the most frequently mentioned problem area,receiving a mention by 16% of the 284 auditmanagers surveyed.

The role of the internal auditor in the maintenanceof system controls presents an important issue.Figure 8 represents the systems related tasksshown through time. Main et aL, [25] represen-ting The Institute of Internal Auditors, see com-puter auditing as the verification of controls inthree areas of the organization: applications,systems development, and the information pro-cessing facility. They suggest that the internalauditor perform function B in Figure 8 (verifyingthat adequate security controls exist), but thatsomeone else should perform function A(monitoring the system and amending the con-trols as necessary). A Conference Board Survey[24] shows that 88% of internal auditors considertheir role to include the review of data processingcontrols, but 70% also become involved in thedevelopment process to simplify subsequentauditing. They emphasize the role of review asagainst (]esign to avoid compromising the check-ing function.

No literature was located that dealt with functionA. Possibly producers who are pressured andoverworked have been content to leave the taskof identification of problem areas to internalauditors. With the increasing use of sampling onthe part of auditors, this could be dangerous.



Manual procedures specification

The literature relating to the design of non-computer aspects of computer systems (for in-stance, the design of forms) grew out of theorganization and management literature with slightadaption for the differences involved in computerprocessing. The literature has not developed in-dependently. That which does exist is primarilyconcerned with systems creation virtually to theexclusion of maintenance, with repeated mentionof the need for regular reviews.

sidered in the literature. A survey of data process-ing managers undertaken by Lientz and Swanson[19] identified inadequate user training as one ofthe six major problem areas in maintaining applica-tion systems. They suggest ongoing training asan important element of the maintenance func-tion. Ramsgard [28] discusses the use of an in-ventory containing samples.of all reports as atraining aid. He suggests that no new managershould be allowed to receive any computerreports until he has reviewed in detail the inven-tory of reports.

DatabaseIt is clearly important that data items and transac-tions be added to, amended, and deleted fromthe database. It is of such importance and soclearly vital to operations that systems are design-ed (at the development stage) to maintain thedatabase. The ease of usage of such systems is amajor attraction to DBMS. The problems en-countered in adding data structures and changingthe format of existing structures has been con-sidered at length. However, such considerationsseldom venture beyond the immediate systems

- element and hence integration of elements isslight. The major exception to this is the securityaspects incorporated into database systems.

This is one of the few systems elements in whichmaintenance is designed into the system from theoutset. As database management systems havedeveloped, the implemention of changes both tothe data and to the structure of the database haveeased considerably.

Training

The training area has not changed significantlywith the introduction of computer-based systemsapart from the recent innovation of including train-ing and assistance information within an applica-tion program to aid clerks and users alike. Thecontent of training programs, more often than not,has focused on potential or existing systemsanalysts and programmers, although some dofocus upon user managers. Such training for usermanagers is often not organizationally centerednor systems specific.

Seldom is the continuing availability of personneltrained in particular application systems con-

Specification and documentationThis area of maintenance is of great practical im-portance and has attracted academic and profes-sional attention because it is virtually unavoidable.Producers do not need to monitor users’ chang-ing needs (users will inform the producer in nouncertain terms if the changes are important). Nordo producers need to evaluate systems security(again, problems will become very obvious or In-ternal Audit will inform the producer of any inade-quacies). But producers do need to correct system that fails. One must consider, however,that corrective software maintenance is usuallyregarded as a small part of the total softwaremaintenance task (between 19 and 21% of thetotal software function [19, 20]). Other reasonsfor software maintenance -- perfective and adaP-tive -- will also be difficult to avoid. User pressurefor systems improvements can become very in-tense. In other cases, a new model of computerwill demand software changes before it will pro-cess existing applications.

The literature can be classified into four groups orissues.

Cost of Maintenance -- A search of the literaturefailed to locate studies that isolate the cost ofsystems maintenance as defined here, but anumber of investigations highlight a subset of this-- the cost of software maintenance [5, 13, 16,17, 19, 29, 32, 33].

Tracing, Recording and Costing SoftwareAmendments -- These range from very simple[34] to the more complex computer basedsystems [12] and are directed toward softwaremaintenance cost analysis, [1, 32, 33], general



related statistics [27, 29, 30], and securityaspects [31] of implementing changes to soft-ware.

Motivation of Software Maintenance Staff --The benefits accruing from integration or separa-tion of maintenance from development forms thefocus of attention.

Improved Programming Techniques to Easethe Maintenance Problems -- The United StateGeneral Accounting Office [33] identified the im-proved use of tools and techniques as the secondmost effective way to reduce maintenance costs.Ewers and Vessey [12] discuss 15 programmerproductivity tools which they classify under theheadings of: tools used in the programming en-vironment, tools used in the program creationfunction, and program testing tools. Theyespecially emphasize the maintenance benefitsfrom such productivity tools. Donahue [9] usesover 1 O0 pages to extensively describe softwaremaintenance tools and techniques in great detail.Discussions of software tools tend to betechnical, and utilization often involves the pur-chase of particular software aids marketed bycomputer manufacturers and other large softwareproducers.

Resource requirements

If producers are to play any significant rolein maintenance, resources will be required. Lientzet al., [20] report that most senior managersregard software maintenance as more importantthan development and hence, if the survey wasrepresentative, resources may well be madeavailable for software maintenance. Glass andNoiseaux [15] profile a software maintainer whichdemands the qualities of a superman: flexibilty,broad background, patience, self motivation,responsibility, humility, innovation, and anhistorian. Authors agree that, in reality, the mostinexperienced, the most inept, or the personmost easily pressed into service is often utilized.

Organizational design

Tipshus and Sanderson [31 ] suggest a novel formof organization for software maintenance. Theysuggest creating a project team for developmentconsisting of transients (who will move on to other

systems when the demand for resources isreduced), and fixtures (who will stay with thesystem on a more or less permanent basis).Knowing from the outset that one is to be involvedin the maintenance of a system may well en-courage one to develop adequate documenta-tion. Freedman and Wienberg [14] suggest ad-ding maintenance staff to the post-implementationreview committee to achieve this same objective.Cooper [7] suggests a variant of this whereby apermanently assigned program maintainer joinsthe development group to ease the transitionalproblems. Lientz and Swanson [19] report thatseparation of maintenance and developmentleads to increased efficiency, although this wasby no means the usual method of organizationnoted. Other cases of alternative organizationalmethods can be found [31 ].

Communication channelsSystems maintenance depends on open com-munication channels between producers andusers. A British Computer Society study [4]reveals user/producer communication as an im-portant problem area. Edwards [11 ] confirms theimportance of.this aspect. Land [18] enumeratesreasons for communication failures.

DiscussionThis article has attempted to show that systemsmaintenance should involve all elements in anoperational system. A review of the literaturereveals a dearth of literature for the majority of theelements of systems maintenance and a nearlytotal fragmentation into non-interacting specializa-tions. This section offers positive direction in themaintenance dilemma by integrating proposalsfrom many sources.

Why is the present situationso unsatisfactory?The question of why this situation is presently un-satisfactory must be addressed before becominginvolved in a consideration of action. Organiza-tions spend thousands, if not millions of dollarsdeveloping computer-based information systems



with the intention that any individual system willlast for a number of years. Clearly, informationsupport for the managerial tasks must have beenimportant when the system was first developedand, unless a major change in organizationaltasks and roles has occurred, information supportwill still be of importance. As time passes andorganizational changes occur, the system mayyield progressively less value. The users, havingbecome familiar with the original system, willpossibly be requiring systems enhancements toincrease the value yielded. Hence, the gap bet-ween the value potentially and actually yieldedbecomes wider. Awaiting the obsolesence of asystem before developing a replacement is un-satisfactory. For most of the life of that system, itwill not be providing the required information, andextremely significant problems could occur by notkeeping the system current. For example,breaches of security could occur resulting in themisplacement of millions of dollars. Liken this lackof maintenance to the purchase of any otherorganizational asset that depreciates, say amachine or a new building, and the need forsystematic maintenance becomes patently ob-vious. A continually evolving system to meetchanging organizational circumstances would ap-pear preferable to a quickly degenerating asset.In addition to these major points, the aggravationinvolved in users having to utilize an unsatisfac-tory system can hardly be productive.

All of these comments addressing the need formaintenance hinge upon change occurring in theorganization through time. Even though somesystems in an otherwise changing organizationmight not be effected Lincoln [21] identifies anumber of organizational and environmentalpressures that would suggest that static organiza-tions should be most uncommon.

Selecting a philosophyFigure 7, which cross references inputs to andoutputs from the systems development process,is actually cross referencing two possible focusesof the maintenance function. First, a maintainercould adapt a reactive philosophy which involvesawaiting demands for maintenance and adjustingthe system’s elements to satisfy the specifiedchange. Such a method is effectively reacting tochanges that become apparent. Programs wouldbe amended if they fail, improved if changes are

pressed by users, security procedures would betightened after a failure becomes apparent, usertraining would be available upon request. Such asystem would be proportionately inexpensive tooperate, but the value yielded by the system mayalso be similarly small.

An alternative philosophy, here termed proactive,would involve monitoring changes that occur inthe information inputs to the design process and,by using a chart of the form of Figure 7, tracingthe effects of each input change upon theelements in the system. Such a system would, forinstance, demand the encumbent of a position toreappraise each report received for its utilitywhen a particular organizational position is chang-ed. Further, even if a manager filling a position isnot replaced, he will need to be monitored to en-sure that his needs, upon which the reports weredesigned, have not changed.

A combination of these two philosophies is clearlypossible, whereby certain systems elements areconsidered on a reactive basis and others aremonitored on a proactive basis. For instance,users might be monitored on a proactive basiswhereas software might be-organized on a reac-tive basis.

Selecting a maintenance philosophy will dependprimarily upon the projected degree of change inthe environment of the system and the costs ofalternative maintenance systems. Such variablesare difficult to quantify. The projected degree ofchange and its projected effects can best befound by undertaking appraisal of each informa-tion input to the development process. Certainapplications addresssing particular tasks (for ex-ample, word processing) appear to requirechange less frequently than systems that arereport specific (for example, order analysis repor-ting). The consequences of an ill-suited informa-tion system can vary widely. The cost of alter-native systems of maintenance, although not sim-ple, is somewhat easier to appraise.

When to consider maintenance

Maintenance should be considered at thesystem’s design and creation stages: it should notbe an afterthought. Either a separate task in thedevelopment cycle titled ’design maintenanceprocedures’ is originated ora part of every



systems element should be devoted tomaintenance. This is impossible for existingsystems, but no further systems proposalsshould be drafted or accepted without including aclear consideration of how each element is to bemaintained. Systems design of the maintenancefunction includes not only a discussion of what isrequired to be performed but also who is to do itand how it is to be organized.

Allocating responsibility

The design of maintenance procedures should bethe responsibility of the system designer.Responsibility for the maintenance function canbe performed by users, by producers, some byeither, and some by both. As a starting point, itwould seem reasonable to allocate the respon-sibility for each element to the group that wasresponsible for producing it. This would imply thatif system analysts wece involved in defining userneeds, they would be continually involved innoting changes that effect those needs. To turnresponsibilty for maintenance over to users, as isimplied when authors suggest ’signing off,’ re-quires that the users have learned a great dealfrom their participation in the development pro-cess. Further, it implies that they have the re-quired degree of overview of the whole system torealize the implications of change. If such a turn-over of responsibility is envisaged, exhaustiveuser training will be needed. Lientz and Swanson[19] suggest that enhancements in terms of ad-ditional reports could be processed by users withthe use of report generator languages whereasenhancements that demand changes to thedatabase would be processed by producer staff.Whatever the division of responsibility, it is vitalthat someone has responsibility for the successof maintenance just as the leading systemsanalyst has in the development function.

Resource requirements

There is a need for senior management torecognize the need for, and importance of,systems maintenance in order to allocate ade-quate resources. Previously discussed researchsuggests that senior managers do recognize thisneed. The extension of these perceptions fromsoftware maintenance to systems maintenance

does not necessarily follow, although the logicunderlying the importance of systemsmaintenance might well encourage support.

Developing communication channels

Systems maintenance depends on open com-munication channels between producers andusers. Communication can be achieved in a varie-ty of formal and informal ways, but the method ofphysically locating an analyst with a group ofusers to service a single system appears to meetthe objectives of a close contact with users. Yet,in extreme cases, this may isolate analysts fromproducers. Many other organizational possibilitiesexist to facilitate communication: for example,systems discussion groups, regular systemsreviews, informal activities, and advanced trainingsessions.

The evolving role of theinternal auditor

The internal auditor has been mentioned in rela-tion to the maintenance of various elements. Theobvious extension of this responsibilty was sug-gested by Lientz and Swanson [19] in theirrecommendation for life cycle audits. They did notcontrast the roles of maintenance as an ongoingtask, and audit as a final checking function. Ratherthan being seen as a first line maintainer, theinternal auditor should be seen as the final checkon efficient and effectiye operation by inves-tigating all systems elements. To safeguard com-promising their position, auditors should notbecome associated with the systems main-tenance function.

Attitude changesTwo related, but apparently minor points might bevaluable in securing effective systems main-tenance. First, the title maintenance hardlyengulfs the wider organizational tasks envisagedin this article. Such a title suggests merely strivingto ensure that an initially given value persists.Systems evolution, or some similar title, mightmove away from the narrow meaning of main-tenance, toward a definition of striving to increasethe value of the system to the organization. A sec-



ond point involves changing the attitude ofdevelopment staff to regard the new task ofsystem evolution as equally important as systemdevelopment.

The effects of distributeddata processing upon themaintenance functions

A final point worthy of consideration is the effectsof distributed processing upon the systemsmaintenance function. There are many shades ofdistribution ranging from near centralization of allsystems elements to full user autonomy increating and operating systems, The wide varietyof situations that are labelled as distributed pro-cessing would lead to an extensive discussion ofthe effects of distributed data processing uponthe maintenance activity. Such a discussionwould not be suitably presented in this paper, butglobal comments might be appropriate.

The control of elements by a single departmenthead will likely lead to an advantageous trade-offbetween benefits and costs. The benefits ofsystems maintenance in terms of improved infor-mation will be known to the operating departmenthead, in addition to the costs. A choice as toresource allocation can be made based upon fullinformation and with less political interference.The monitoring of either systems elements, or in-formation input, will be considerably simpler toorganize given it is the responsibility of a singleperson. The changes are occurring in the depart-ment in which the maintainer is employed, andhence the communication problem should bereduced.

Reasons for the Neglectof MaintenanceOne major question remains to be addressed:why, if systems maintenance is so important, is itso neglected in practice and academia?

Considering the former, four points appear rele-vant. Firstly, it is often noted that analysts andprogrammers prefer to be concerned with thedevelopment of new systems rather than themaintenance of existing systems. Glass and

Noiseux [15] include a discussion of six majorpoints why analysts and programmers are not at-tracted to maintenance:

maintenance is intellectually very difficult

maintenance is technically very difficult

maintenance is unfair; necessary informa-tion is not available; original program writersget promoted even though they leave amess behind them

maintenance is no-win; people only cometo maintenance with problems

maintenance work does not result in glory,noticeable progress, or chances for "suc-cess"

maintenance li~es in the past, the quality ofyesterday’s coding is often very poor

These points combined with a world shortage oftrained staff does not encourage senior managersto insist on maintenance; computer staff are alltoo mobile.

Second, it may not be in an analysts interests toadd all of the very significant cost of maintenanceinto the cost/value proposals for risk of fewer pro-jects being undertaken. The underestimation ofmaintenance cost in proposals makes it some-what difficult to request additional staff oncesystems are implemented. It is easier to severelylimit the activity to that which is absolutelynecessary. Any additional costs can be hiddeneither in the development of subsequent systemsor through the non-analysis of costs; a practicethat thas been noted [33]. Comparing projectedwith actual maintenance costs would demand asophisticated accounting system and even thenmany reasons could be found for the huge dif-ference. If, by chance, such information wasavailable, an analyst would be even more temptedto do less maintenance.

Third, When a department experiences very highservice demands with a relatively fixed budgetsomething has to suffer: the usual attitude inmany walks of life is to select aspects which areleast pressing from a short-term viewpoint andmost difficult to measure. Systems maintenance,apart from software correction, appears to be anobvious choice.



Lastly, maintenance has not been acceptedhistorically as a major task. The author canremember when, working as a junior programmer,a discussion centered upon the fate of the pro-gramming staff when all the organizationssystems were fully programmed: viewingmaintenance as a minor function is all tooprevalent. To change such perceptions demandsa major effort that may take a considerable periodof time.

These foregoing arguments may suggest whymaintenance is neglected in practice but does notexplain why the area has received so little atten-tion from academics. Apart from a very smallnumber of noted people, research on themaintenance issue has been neglected. This ap-plies, to a lesser extent, to all areas of MISresearch. As in other areas of academia, there isa tendency to research where a body ofknowledge already exits (see, for instance, theMIS research developing out of cognitivepsychology [34]). To be among the few workingin an area is unfashionable and often leads topapers such as this where the discussion can_only suggest the most tentative of actions.

A ckno wledgements

My thanks are offered to John Handley for manyhelpful comments offered on an earlier draft ofthis article.

References

[1] Bernard, D., Emery, J.C., Nolan, R.L., andScott, R.H. Charging for Computer Ser-vices: Principles and Guidelines,EDUCOM, 1977.

[2] Berrisford, T., and Wetherbe, J. "HeuristicDevelopment: A Redesign of SystemsDesign," MIS Quarterly, Volume 3, Number1, 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 Re-quirements in Data Processing, Heydenand Sons, London, England, 1979.

[5] Canning, R.G. (ed.)"That MaintenanceIceburg," EDP Analyzer, Number 10,1972.

[6] Comptroller General of the United States"Standards for Audit of GovernmentOrganizations, Programs, Activities, andFunctions," Washington, DC, 1972.

[7] Cooper, J.D. "Corporate Level SoftwareManagement," IEEE Transactions on Soft-ware Engineering, SEo4, July 1978, pp.319-325.

[8] Davis, G.B. "Strategies for Information Re-quirements Determination," IBM SystemsJournal, Volume 21, Number 1, 1982, pp.4-30.

[9] Donahue, J.D., and Swearinger, D. AReview of Software MaintenanceTechnology, ITT Research Institute, RomeAir Defence Centre, RADC-TR-80-13,New York, New York, 1980.

[10] Drury, D.H. "Conditions EffectingChangeback Effectiveness," Informationand Management, Number 5, 1982, pp.31-36.

[11] Edwards, C. "Determinants of SuccessfulInformation Systems Maintenance." Un-published Ph.D Dissertation, University ofStrathclyde, Glasgow, Scotland, 1980.

[12] Ewers, J. and Vassey, I. "The SystemsDevelopment Dilemma -- A ProgrammingPerspective," MIS Quarterly, Volume 5,Number 2, June 1981, pp. 33-45.

[13] Frank, W. The New Software Economics,United States Professional Development In-stitute, Inc., Silver Springs, Maryland,1979.

[14] Freedman, D.P., and Weinberg, G.M.Guide to Walkthroughs, Inspections andTechnical Reviews, Winthrop Publishers,Inc. 1982.

[15] Glass, R.L., and Noiseux, R.A. SoftwareMaintenance Guidebook, Prentice-Hall,Inc., Englewood Cliffs, New Jersey, 1981.

[16] Hoskyns Systems Research Centre, "Im-plications of Using Modular Programming,"Guide Number 1, John Hoskyns and CoLtd, New York, New York, 1973.

[17] Khan, Z. "How to Tackle the SystemsMaintenance Dilemma," Canadian DataSystems, March 1975, pp. 30-32.

[18] Land, F. "Adapting to Changing User Re-quirements," Information and Management,Number 5, 1982, pp. 59-75.



[19] Lientz, B.P., and Swanson, E.B. SoftwareMaintenance Management, Addison-Wesley Publishing, Reading, Massa-chusetts, 1980.

[20] Lientz, B.P., Swanson, E.B., and Tom-pkins, G.E. "Characteristics of ApplicationSoftware Maintenance," Communicationsof the ACM, Volume 21, Number 6, 1978,pp. 266-471.

[21] Lincoln, T.J. "Impact of the ChangingBusiness Environment on Management andTheir Information Needs," ManagementDatamatics, Volume 5, Number 3, 1976,pp. 105-111.

[22} McCosh, A.M., Rahman, M., and Earl, M.J.Developing Managerial InformationSystems, John Wiley and Sons, New York,New York, 1981.

[23] McKell, L.J., Hansen, J.V., and Heitger,L.E. "Charging for Computing Resources,"Computer Surveys, Volume 11, Number 2,1979, pp. 105-120.

[24] Macchiaverna, P. Internal Auditing, TheConference Board, New York, New York,1978.

[25] Mair, W.C., Wood, D.R., and Davis, K.W.Computer Control and Audit, The Instituteof Internal Auditors, Inc., AltamonteSprings, Florida, 1976.

[26J Martin, J. Security, Accuracy and Privacy inComputer Systems, Prentice-Hall,Englewood Cliffs. New Jersey, 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, NewYork, 1977.

[29] Riggs, R. "Computer SystemsMaintenance," Datamation, Volume 15,November 1969, pp. 227-235.

[30] Swanson, E.B. "The Dimensions ofMaintenance," Proceedings 2nd Interna-tional Conference on Software Engineer-ing, San Francisco, California, 13-15 Oc-tober 1976, pp. 422-497.

[31] Tipshus, E. and Sanderson, J. "Rotating’Rival’ Programmers Between Applicationsand Maintenance Dampens Antagonism,Improves Documentation," Data Manage-ment, Volume 18, June 1 980, pp. 42-46.

[32] Tompkins, G.E. "Characteristics of the

High Cost of Maintenance," UnpublishedPh.D Dissertation, Graduate School ofManagement, University of California, LosAngeles, California, 1977.

[33] United States General Accounting Office"Federal Agencies’ Maintenance of Com-puter Programs: Expensive and Under-managed," AF MD-81-25, 1981.

[34] Zmud, R.W. ’,Individual Differences andMIS Success: A Review of the EmpiricalLiterature," Management Science, Volume25, Number 10, 1979, pp. 966-979.

About the Author

Professor Chris Edwards (MA PhD FCMA) is Professor of Management Information Systems atthe Cranfield School of Management. He taught atthe University of Strathclyde between 19 73 and1981. From then until 1983 he was researchingand teaching at the Carnegie-Mellon GraduateSchool of Industrial Administration. Professor Ed-wards joined Cranfield School of Management in1983. He is particularly interested in theorganizational problems encountered bybusinesses using microcomputer-based informa-tion systems. He is also involved in researchrelated to the effectiveness of different types ofinformation presentation, in particular the effec-tive use of graphics.

256 MIS Quarterly/December 1984

Documents

Information Systems Maintenance: An Integrated …...For instance, installation, security, file management, and engineering maintenance are usually discussed without reference to any