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
reviewedto reveal substantial underdevelopment
someareas andfragmentationbetweenelements.The
presentpractice of focusing uponthe maintenance
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 im-
plemented.The latter task is knownvariously as
systemsmaintenance,applications maintenance,
systems management, systems audit, post-
implementation 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 pro-
cess 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 anypar-
ticular 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 offer-
ing very great development specilization,
systems creation involves very few functional
specializations whereassubsequent operation
usually involves a greater number.Personnelin-
is
volved in operations maywork on a numberof
in
systems in one day, whereas development per-
of sonnel maywork for manymonths on a single
system. For this reason, operation demandsa
greater degreeof functional integration. This arti-
cle 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, main-
tenanceis being neglected.
This article focuses upon centralized data pro-
cessingorganizations, as the majority of applica-
{:: .,.,
tions 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.

O O
Systems Maintenance
Definitions of maintenancevary in a computer-
related context. Boehm[8] distinguishes be-
tween software update and software repair. The
former involves enhancements whereasthe latter
ensuresthat the programsperformas first intend-
Development ~ Perspective ed. Ogdin [27] includes both of these under
(.-
.g maintenancebut introduces the term modification
to include changesthat result from a developing
environment. Riggs [20] movestoward a wider
0 view of maintenancein his definition:

"Systemsmaintenanceis the activity

associated with keeping operational
computer systems continuously in
tune with the requirementsof users,
data processing operations, asso-
ciated 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 B. Adaptive maintenancearising from:

1 Changesin the data environment.
2 Changesin ’the processing environment

238 MIS Quarterly~December1984


C2
The System
Application
Software
~
A1 A2, A3, C1, C3.
B1
Environment
Figure 2 -- A Representation of Swanson’sDemands
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 amend-
ing, 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 soft-
ware 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
Information SystemsMaintenance
for Software Maintenance
that wherever a demandarises the effect is to
cause an amendment to the applications soft-
ware. Changesin the data environment (B1)
presumably occur either because0f changesin
someother unspecified system elementor in the
organizationalenvironment
itself.
Systemsmaintenance,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 ele-
ment (X), somechange occuring in someother
element(Y), or somechangeoccuring in the en-
vironment (Z). A changein any element mayde-
manda 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

Applications
Software

Security
Procedures
V X

The
Database

Users

Figure 3 -- A Representation of Demands

for SystemsMaintenance

240 MIS Quarterly~December1984


chains of required amendments involving
numeroussystems elements.
Building uponthis, systemsmaintenance is defin-
ed 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 ex-
pansion and generalization of Swanson’sclassi-
fication 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 re-
quirementsmight be operationalized.
SystemsLife Cycle
The developmentlife cycle has been defined by
manyauthors with only minor variations. Alter-
native 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
undertakinga brief appraisalas to its suitability
for computerprocessing.
SystemsDesign -- Tasks 3 through 6 de-
manda detailed consideration of user re-
quirements and the proposal of a numberof
outline solutions. Thelast task in this stage
involves evaluating the alternatives and selec-
ting an appropriateaction plan.
SystemsCreation -- Tasks 7 through 1 5 are
the core of the developmentprocess and in-
volvea 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
Information SystemsMaintenance
organizational changesnecessaryto utilize the
newly developed system.
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 re-
quired system. For example, task 1 is an in-
vestigation whichresults in a report whichis used
in task 2. Henceboth task 1 and2 might be view-
ed 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 em-
bodied 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 em-
bodied 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.
Figure 5 recasts the developmentlife cycle label-
ing eachtask as production(p) or control (c),
showsthe resulting systemselements. Interac-
tions 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 por-
tray iteration within tasks and betweentasks as
this wouldconfusethe situation.
Most of the systemsdevelopmenttasks draw in-
formation from the organization and its environ-
ment. 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)
Stage 4
,,mpemenation
!
I1 7)

Post-
I 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 pro-
ceduresfor gathering information relating to the
organization and transforming this into the ele-
ments 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
be monitored other than immediately following
implementation.
Eachof the resulting systemselementshas a time
dimension and may or may not need to be up-
datedas the original informationinputs to that ele-
mentchange.Figure 7 is a cross-reference of in-
formation 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

242 MIS Quarterly~December 1984

 Information SystemsMaintenance

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

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

(18) Post-lmplement~tion
Audit

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 sec-
ond 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 situa-
tions 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 retrain-
ing maynot be necessary. However, every ele-
mentwill 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.

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 prac-
tice will be continuedhere. Secondly,this section
will considerthe literature related to the organiza-
tional 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: ask-
ing, deriving from an existing system,synthesiz-
ing 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 evolu-
tionary approach,recognizes the managerialpro-
blemsinvolvedin 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 contin-
uing process, but as a methodof defining user
needs ultimately resulting in a defined set of
requirementswhich will form the basis for a pro-
cessing system.
Researchrecognizing the continuing needto up-
date user needs is not common.Edwards [11]
Information SystemsMaintenance
reports empirical investigations designedto deter-
mineorganizational 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 encourag-
ing usageof information perceivedas underutilized
by the users’ superiors or the information’s pro-
ducers. (The term producerswill be used here to
denotestaff of the organizationalunit responsible
for developingthe information systemandfor pro-
ducingthe 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 chan-
nels, and
- allocation of responsibility to motivatedper-
sonnel who perceived the maintenance of
user needsas an important activity.
The crudeness of this research can be seen in
the implicit assumptionthat users knowwhat in-
formation 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 sug-
gests that managers either cannot identify or are
unable to express their needs.
Land[18], in synthesizingthe workof others, sug-
gests 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 sug-
gesting that an inventory containingall the essen-
tial 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
SYSTEMS DESIGN
IMPLEMENTATION
ANDINITIAL REVIEW
Internal Verification
Audit Tasks ~’~ of security
(Function B) controls
(Function B)
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 secon-
dary 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 ex-
ceed 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
t~
SYSTEMS OPERATION
-- PERIOD1
Verification
of security
controls
(Function B)
Time
[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 somewhatless
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 hid-
den 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 iden-
tified 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 discussedorganiz-
ing chargeout systemsas part of a maintenance
function.
Security specification
Manyauthors addressthemselvesto the issue of
designing systems that assure availability,
 Information SystemsMaintenance

Monitoring Systems Monitoring. Systems

operation and operation and
amending as amending as
necessary necessary
(Function A) (Function A)

SYSTEMS OPERATION SYSTEMS OPERATION

-- PERIOD2 -- PERIOD3

’T
Verification
Verification
of security of security
controls .controls
(Function B) (Function B)

preserveconfidentiality, and provide information
integrity: Thereis little discussionin the informa-
tion 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 effec-
tive operation. Macchiaverna[24], in a Con-
ference 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] represen-
ting TheInstitute of Internal Auditors, see com-
puter auditing as the verification of controls in
three areas of the organization: applications,
systemsdevelopment, and the information pro-
cessing 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 con-
trols 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 check-
ing 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 non-
computer aspects of computer systems (for in-
stance, the design of forms) grew out of the
organization and managementliterature with slight
adaption for the differences involved in computer
processing. The literature has not developedin-
dependently. That which does exist is primarily
concernedwith systemscreation virtually to the
exclusion of maintenance,with repeated mention
of the needfor regular reviews.
Database
It is clearly importantthat data items andtransac-
tions be added to, amended,and deleted from
the database. It is of such importance and so
clearly vital to operationsthat systemsare design-
ed (at the developmentstage) to maintain the
database. The ease of usageof such systemsis a
major attraction to DBMS.The problems en-
counteredin adding data structures and changing
the format of existing structures has been con-
sidered 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 train-
ing and assistance information within an applica-
tion 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
sideredin the literature. A surveyof data process-
ing managersundertaken by Lientz and Swanson
[19] identified inadequateuser training as oneof
the six majorproblemareas in maintainingapplica-
tion systems. They suggest ongoing training as
an important element of the maintenancefunc-
tion. Ramsgard [28] discusses the use of an in-
ventory 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 inven-
tory of reports.
Specification and documentation
This area of maintenance is of great practical im-
portance and has attracted academicand profes-
sional attention because it is virtually unavoidable.
Producers do not need to monitor users’ chang-
ing 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 In-
ternal Audit will inform the producerof any inade-
quacies). 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 adaP-
tive -- will also bedifficult to avoid.Userpressure
for systems improvements can becomevery in-
tense. In other cases, a new model of computer
will demand software changesbefore it will pro-
cess 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

related statistics [27, 29, 30], and security
aspects [31] of implementing changesto soft-
ware.
Motivation of Software MaintenanceStaff --
Thebenefits accruing from integration or separa-
tion of maintenancefrom developmentforms the
focus of attention.
Improved ProgrammingTechniques to Ease
the MaintenanceProblems-- The United State
GeneralAccountingOffice [33] identified the im-
proved 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 programmingen-
vironment, 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 pur-
chase of particular software aids marketed by
computermanufacturersand other large software
producers.
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
Information SystemsMaintenance
systems when the demand for resources is
reduced), and fixtures (who will stay with the
system on a more or less permanent basis).
Knowingfrom the outset that oneis to be involved
in the maintenance of a system may well en-
courage one to develop adequate documenta-
tion. Freedmanand Wienberg [14] suggest ad-
ding 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 com-
munication channels between producers and
users. A British ComputerSociety study [4]
reveals user/producer communicationas an im-
portant problemarea. Edwards[11 ] confirms the
importanceof.this aspect. Land[18] enumerates
reasonsfor communicationfailures.
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-interactingspecializa-
tions. This section offers positive direction in the
maintenance dilemma by integrating proposals
from manysources.
Whyis the presentsituation
so unsatisfactory?
Thequestionof whythis situation is presently un-
satisfactory must be addressedbefore becoming
involved in a consideration of action. Organiza-
tions 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 bet-
weenthe value potentially and actually yielded
becomeswider. Awaiting the obsolesence of a
system before developing a replacement is un-
satisfactory. 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 ob-
vious. A continually evolving system to meet
changing organizational circumstances would ap-
pear preferable to a quickly degeneratingasset.
In addition to these major points, the aggravation
involved in users having to utilize an unsatisfac-
tory 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 organiza-
tions 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 chang-
ed. Further, evenif a managerfilling a position is
not replaced, he will needto be monitoredto en-
sure 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 reac-
tive 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 informa-
tion input to the developmentprocess. Certain
applications addresssingparticular tasks (for ex-
ample, word processing) appear to require
change less frequently than systems that are
report specific (for example,order analysis repor-
ting). The consequences of an ill-suited informa-
tion system can vary widely. The cost of alter-
native systemsof maintenance,although not sim-
ple, 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

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 respon-
sibility 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,’ re-
quires that the users have learned a great deal
from their participation in the developmentpro-
cess. Further, it implies that they have the re-
quired degreeof overview of the whole systemto
realize the implications of change.If sucha turn-
over of responsibility is envisaged, exhaustive
user training will be needed.Lientz and Swanson
[19] suggest that enhancements in terms of ad-
ditional 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 ade-
quate resources. Previously discussed research
suggeststhat senior managersdo recognize this
need. The extension of these perceptions from
software maintenance to systems maintenance
Information SystemsMaintenance
does not necessarily follow, although the logic
underlying the importance of systems
maintenancemight well encouragesupport.
Developing communicationchannels
Systems maintenance depends on open com-
munication channels between producers and
users. Communication can be achievedin a varie-
ty 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 rela-
tion to the maintenanceof various elements.The
obviousextension of this responsibilty wassug-
gested 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 inves-
tigating all systemselements. To safeguardcom-
promising their position, auditors should not
become associated with the systems main-
tenancefunction.
Attitude changes
Tworelated, but apparently minor points might be
valuable in securing effective systems main-
tenance. 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 main-
tenance,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.
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 pro-
cessing 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 improvedinfor-
mation 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 in-
formation input, will be considerably simpler to
organizegiven it is the responsibility of a single
person. The changesare occurring in the depart-
ment 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 systemsmaintenanceis so important, is it
so neglected in practice and academia?
Consideringthe former, four points appearrele-
vant. 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
Noiseux [15] include a discussion of six major
points whyanalysts and programmers are not at-
tracted to maintenance:
maintenance
is intellectually very difficult
maintenance
is technically very difficult
maintenanceis unfair; necessaryinforma-
tion 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
maintenancework does not result in glory,
noticeable progress, or chancesfor "suc-
cess"
maintenanceli~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 pro-
jects being undertaken. The underestimation of
maintenance cost in proposals makesit some-
what 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 dif-
ference. 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.

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 pro-
grammingstaff 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 atten-
tion from academics. Apart from a very small
number of noted people, research on the
maintenanceissue has beenneglected. This ap-
plies, 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 commentsoffered on an earlier draft of
this article.
References
[1] Bernard, D., Emery,J.C., Nolan, R.L., and
Scott, R.H. Charging for Computer Ser-
vices: 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 Re-
quirements in Data Processing, Heyden
and Sons, London, England, 1979.
Information SystemsMaintenance
[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 Soft-
ware Engineering, SEo4, July 1978, pp.
319-325.
[8] Davis, G.B. "Strategies for Information Re-
quirements 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." Un-
published 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 In-
stitute, 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, "Im-
plications 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 Re-
quirements," Information and Management,
Number5, 1982, pp. 59-75.
MIS Quarterly~December1984 255
 Information SystemsMaintenance

[19] Lientz, B.P., and Swanson,E.B. Software High Cost of Maintenance," Unpublished
Maintenance Management, Addison- Ph.D Dissertation, Graduate School of
Wesley Publishing, Reading, Massa- Management, University of California, Los
chusetts, 1980. Angeles,California, 1977.
[20] Lientz, B.P., Swanson, E.B., and Tom- [33] United States General Accounting Office
pkins, G.E. "Characteristics of Application "Federal Agencies’ Maintenance of Com-
Software Maintenance," Communications puter Programs: Expensive and Under-
of the ACM,Volume 21, Number6, 1978, managed," AF MD-81-25, 1981.
pp. 266-471. [34] Zmud,R.W. ’,Individual Differences and
[21] Lincoln, T.J. "Impact of the Changing MIS Success: A Review of the Empirical
Business Environment on Management and Literature," Management Science, Volume
Their Information Needs," Management 25, Number10, 1979, pp. 966-979.
Datamatics, Volume 5, Number3, 1976,
pp. 105-111.
[22} McCosh,A.M., Rahman,M., and Earl, M.J. Aboutthe Author
Developing Managerial Information
Systems, John Wiley and Sons, NewYork, Professor Chris Edwards(MA PhD FCMA)is
NewYork, 1981. Professor of Management Information Systemsat
[23] McKell, L.J., Hansen,J.V., and Heitger, the Cranfield School of Management. He taught at
L.E. "Charging for ComputingResources," the University of Strathclyde between19 73 and
ComputerSurveys, Volume11, Number2, 1981. Fromthen until 1983 he wasresearching
1979, pp. 105-120. and teaching at the Carnegie-Mellon Graduate
[24] Macchiaverna, P. Internal Auditing, The Schoolof Industrial Administration. ProfessorEd-
Conference Board, NewYork, NewYork, wards joined Cranfield School of Management in
1978. 1983. He is particularly interested in the
[25] Mair, W.C., Wood,D.R., and Davis, K.W. organizational problems encountered by
ComputerControl and Audit, The Institute businesses using microcomputer-basedinforma-
of Internal Auditors, Inc., Altamonte tion systems. He is also involved in research
Springs, Florida, 1976. related to the effectiveness of different types of
[26J Martin, J. Security, AccuracyandPrivacy in information presentation, in particular the effec-
Computer Systems, Prentice-Hall, tive use of graphics.
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.
[29] Riggs, R. "Computer Systems
Maintenance," Datamation, Volume 15,
November 1969, pp. 227-235.
[30] Swanson, E.B. "The Dimensions of
Maintenance," Proceedings 2nd Interna-
tional Conference on Software Engineer-
ing, SanFrancisco, California, 13-15 Oc-
tober 1976, pp. 422-497.
[31] Tipshus, E. and Sanderson, J. "Rotating
’Rival’ Programmers BetweenApplications
and Maintenance DampensAntagonism,
Improves Documentation," Data Manage-
ment, Volume18, June 1 980, pp. 42-46.
[32] Tompkins, G.E. "Characteristics of the

256 MIS Quarterly/December1984