Managing Information Technology

Chapter 9 • Methodologies for Custom Software Development 369

Because both business and technology environments
change rapidly, periodic changes to large systems are typi-
cal. In the past the total costs over a typical system’s life
cycle have been estimated to be about 80 percent on main-
tenance and only 20 percent on the original development
of the application. As a result, many IS organizations have
to allocate a significant number of their IS specialists to
maintaining systems, rather than developing new ones. In
the early 1990s, maintenance resources were consuming as
much as 75 percent of the total systems development re-
sources in many large organizations (see Figure 9.5). The
IS organization is responsible for making the required
changes in the system throughout its life, as well as for
eliminating any bugs that are identified prior to launching
the new system in a production mode.
To make a change in a system, the maintenance pro-
grammer must first determine what program(s) must be
changed and then what specific parts of each program need
to be changed. The programmer must also understand the
logic of the part of the code that is being changed. In other
words, one must understand the system in some detail in
order to change it.
Because systems can be very complex, system doc-
umentation is critical in providing the necessary level of
understanding. This brings up another difficulty—the
documentation must be changed when the system is
changed or else the documentation will provide mislead-
ing information about the system rather than assistance in
understanding it. Most programmers are primarily inter-
ested in programming and are not rewarded for updating
the documentation, so in many IS organizations the docu-
mentation of old systems becomes outdated and includes
inaccuracies.
Furthermore, when changes are made in complex sys-
tems, a ripple effectmight be encountered such that the
change has an unanticipated impact on some other part of

the system. For example, a change in a program can affect

another program that uses the output from the first program.

A change to a line of code can affect the results of another

line of code in an entirely different part of that program.

Another change must be made to correct those problems and

that change might cause unanticipated problems elsewhere.

Another major problem with maintenance is that

most IS professionals prefer to work on new systems using

new technologies rather than maintain old systems.

Maintenance is therefore often perceived as low-status

work, although it is critical to the business. Maintenance is

often the first assignment of a newly hired programmer,

and most organizations do not have mechanisms to ensure

that really good maintenance people are rewarded well.

From the business manager’s perspective, the major

maintenance challenges are getting it done when it is needed

and dealing with new system problems introduced as part of

the maintenance process. A high proportion of operational

problems are caused by errors introduced when making

maintenance changes. Changes to production systems need

to be carefully managed. Maintenance changes are typically

made to a copy of the production system and then fully tested

before they are implemented. An effective release manage-

mentprocess for changing from an older to a newer version

of the system is critical to avoid introducing large numbers of

new problems when maintaining operational systems.

If adequate numbers of IS specialists are not avail-

able for systems maintenance projects, the manager often

must suffer long delays before needed changes are made.

Figure 9.6 graphically displays the widening gap that can

occur between the organization’s needs and the system’s

performance over time. Also, as a system gets older and is

repeatedly patched, the probability of performance prob-

lems becomes even greater and reengineering or replace-

ment solutions might be required.

New development

100%

Maintenance

Time

Percent of

Development Resources

FIGURE 9.5 Percent of Development Resources Devoted to
Maintenance

Needs of the

Organization

Performance of

the System

Time

Performance Requirements

FIGURE 9.6 The Widening Gap Between the Organization’s

Needs and the System’s Performance