🚀 go-pugleaf

File 5 of  6

                          Behind the Terminal:
             The Critical Role of Computing Infrastructure
         In Effective Information Systems' Development and Use


                               Rob Kling
             Department of Information and Computer Science
                  Public Policy Research Organization
                        University of California
                            Irvine, Ca 92717
                              714-856-5955
                        email:kling@ics.uci.edu

                               Draft 4.02
                      July 17, 1991 (Aug 4, 1991)

To appear in: Challenges and Strategies for Research in Systems
Development. William Cotterman and James Senn (Ed.). John Wiley,
London.

5.0 COMPUTING INFRASTRUCTURE AS AN ORGANIZATIONAL PHENOMENON

In this section we examine the infrastructure of computing as a
central feature of systems in organizations. Specifically, we
will examine 1) how the organizational relationships in which
computing developments are embedded influence their relative
workability for participants; 2) the co-requisites of computing
developments; and 3) the constraints placed upon developers and
users from historically accumulated commitments.

When automated information systems are operated "routinely," the
array of supporting resources strongly influences the quality of
computer-based service which is actually available to users.  The
infrastructural resources for a given activity refers to those
adjunct resources which help carry out the activity smoothly.
Urban planners refer to such physical basics as roads, sewers,
and utilities, which support social and business activities as
the "urban infrastructure." Infrastructural resources for using
reports from a computer-based information system include skilled
staff, accurate and complete documents, sharp operations
procedures, and enforceable equipment contracts.  For software
developers, infrastructure includes programming skills,
information about systems, working hardware, etc.  For computer
hardware, critical infrastructural resources also include
physical systems such as reliable "clean" electrical energy and
low-noise communication lines.



5.1 Identifying Infrastructural Resources

     Discrete-entity analysts can assume that infrastructural
resources are available as needed, so they often overlook
important resource gaps. Web analysts try to account for the
actual bundle of supporting resources available to different
participants, so they need a way to identify them.  We identify
key infrastructural resources by following the chain of
resources, equipment, consumers and providers which support a
given computing resource.  This network is called the "production
lattice" for the focal computing resource (Kling and Scacchi,
1982; Kling, 1987).  Those resources that each consumer/provider
depends upon constitutes an element in the infrastructure for the
focal computing resource.  We have found three ways to identify
the production lattice for a particular computing resource:

PL1. Trace the chain of social and technical interactions from
     the focal computing resource outward to various suppliers of
     basic resources and skills which enable it.  These basic
     inputs include data, supporting equipment, energy,
     communications, etc.  They also include participants who
     provide expert assistance, ensure that basic inputs of
     adequate quality are provided by negotiating with suppliers,
     training resource producers, auditing the quality of inputs,
     etc.

PL2. Include those inputs or resources whose alterations yield
     (large) improvements in the quality of output provided by
     the focal computing resource.

PL3. Include those inputs or resources whose failures reduce  the
     quality of the focal computing resource.

     Criterion C2 (from Section 4.2) guides how far outward from
the focal computing resource one should follow the chain of
dependencies indicated by criterion PL1.  Narrow boundaries drawn
close to the computer room miss the dependencies of computerized
information systems on other organizational resources such as
inter-office mail and telephone lines.  Narrow boundaries miss
relations with equipment vendors or outside consultants which may
also be critical. (See also, Kling, 1987)

======================================

     Selected Infrastructural Resources for Text Processing

                             Table 3

       MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM

1    Text Processor: - WordPerfect
     1.1  System information (e.g., documents, consultants)
     1.2  System alterations (e.g., update procedures, purchasing
          arrangements for updates)
          1.2.1 Availability of undergraduate help
     1.3  Vendor: update and bug fix policies
          Project systems administrator -- technical and social
          skills, availability and scheduling
     1.4 Availability of undergraduate systems support for
updates and configuration management
2    Organizing text files
     2.1  Accurate Data for papers (e.g., data auditing and error
          correcting procedures)
     2.2  Skilled data feeders
     2.3  Training staff
     2.4  Data integrity -- (procedures for compensating for
          crashes) Information paths (e.g., inter-office mail)
          2.4.1     Statistical Computing Support
          2.4.2     System information (e.g., documents,
                    consultants)    Vendor support for revisions
                    and bug patches
          2.4.3     Programmers' skills
3    Operating System: MSDOS for PC
     3.1  System information (e.g., documents, consultants)
4    Hardware: IBM PC + (disc, floppies)
     4.1  Dot matrix printers owned by DCRP in each location
     4.2  Laser Printers: HP Laserjet owned by DCRP,
               Apple LaserWriter owned by PPRO,
                    access to ofice printer space owned by PPRO
               Access to PC driving printer
                    proper printer drivers
               Communication lines from PPRO and homes to ICS
               ICS minicomputers which drive ICS Imagen laser
               printers                 access to printer space
               owned by ICS

5    Skilled users
     5.1  Systems Manuals
     5.2  People with time to train new users
6    Operations procedures
7    Electrical power
8    Physical Space
9    Policies, procedures, and practices for allocating resources
     in PPRO and ICS

======================================

     Table #3 lists some typical infrastructural resources for
computerized text processing in the Desktop Computing Research
Project. The infrastructural resources are those things which
help various actors use the text processor and which support
production lattices defined by criteria PL1, PL2, and PL3.  The
elements of Table #3 are primarily static, and we will examine
three static characteristics first:

a.   Infrastructural resources are layered.  The focal computing
     resource for one participant (e.g., the  operating system as
     seen by a systems programmer) is infrastructure for
     participants further up the (production) chain.
     (Infrastructure is a relationship between a focal resource
     and a supporting resource.) The computing infrastructure in
     organizations has often become  more complex with the spread
     of multiple systems with different components in different
     organizational units and systems connected through
     communications networks. The communications wiring diagrams
     often just hint at the social complexity of the
     infrastructure for specific applications which draw data
     from one system, process it on another, and print it on
     third. When system components are owned by different
     departments and located in different physical locations,
     practical usage is sometimes complicated.

b.   Infrastructural resources for computing may be coextensive
     with or part of other organizational procedures and
     resources.  At various points, the  mail room which
     disseminates reports, the  systems which provide electrical
     power and air conditioning, procedures for hiring and firing
     staff, or for procuring equipment,  can be drawn into the
     support of a focal computer system. In the case of the DCRP,
     the PI recruited some computer science undergraduates to
     learn about the management of a decentralized computing
     environment and to help administer the projects PCs in
     exchange for course credit. But these students' availability
     was influenced by demands from their other courses,
     including somewhat predictable examination schedules.

c.   Some of the resources are relatively concrete objects (e.g.,
     a document, contract), or people (e.g., skilled
     programmers).  Others are  capabilities for reproducing
     these more concrete resources on demand (e.g.,  the ability
     to hire or train skilled programmers, the ability to
     purchase, or  write new documents).

     Computer-based systems are often tightly coupled through the
various elements of infrastructure, both horizontally (through a
particular production lattice) and "vertically" through various
layers.  In the case of many computer systems,  each of these
layers is itself a relatively complex work organization.  For
example, when the DCRP staff used a laser printer in ICS to print
a document, they relied upon their PC, text processor and all of
its supporting arrangements. They also relied upon communication
lines between their workplace and ICS, as well as the
availability of ICS minicomputers. These were not always
available, since communication lines might be congested towards
the end of the academic quarter and the minicomputers might be
"down" for preventive maintenance, file backups, or unexpected
failures. Last, they depended upon the availability of the laser
printer and its resources, such as toner, paper, and people
skilled in fixing paper jams.

     Computer-based technologies and arrangements for using them
vary considerably in the scale and complexity of the production
lattices which support them.  The production lattices supporting
a programmable calculator used by an engineer may be very small
(e.g., sources of design data in the firm and vendor support for
repairs).  On the other hand, information systems which cut
across many organizational subunits (e.g., accounting systems,
inventory control systems) or which cut across many organizations
are much more complicated (e.g., National Criminal Information
Center which is operated by the FBI and whose main systems for
"wants and warrants" and stolen cars are available to police
forces nationwide.)

     Any user of a complex computer-based system used to support
some instrumental lines of work, stands at the intersection of
two work organizations.  One work organization is framed around
the instrumental tasks enacted by the computer user (e.g.,
production planning in a manufacturing firm, actuarial analyses
in an insurance firm, land use analyses in an urban planning
department, or processing various transactions -- payroll checks,
work orders, purchase orders, travel vouchers).  The second work
organization is visible as he faces the computer system and other
core resources (e.g., data sources) which support his
computational universe: the production lattices which provide any
of the computer based products in use.

     For example, when the DCRP staff were revising a complex 200
item questionnaire in the Winter of 1989 and tried to print it
with PPRO's laser printer, they faced two work organizations that
were loosely coupled. Two DCRP research assistants and the PI
worked intensively on  developing the questionnaire in time for a
survey. PPRO's office staff were working on other projects with
equally pressing deadlines. As the survey deadline approached,
one RA was frantically trying to refine the formatting and
correct problems. She wanted substantial access to PPRO's
postscript-compatible laser printer, because WordPerfect 5.0's
screen preview was sometimes imperfect for displaying numerous
boxes and lined borders on the questionnaire. PPRO's office staff
were willing to allow her some casual, but limited usage.

     This production lattice slices through several of the
distinct layers of the computing infrastructure.  The user of
several different computer-based systems stands at the
intersection of several different work organizations: his own
instrumental activities and a production lattice for each
computer-based system.  These lattices may overlap, to the extent
that the computer-based systems ride on shared resources, or they
may be quite distinct.  Discrete-entity analyses view the smooth
coordination of these multiple work organizations is
straightforward.  For web analysts they can be problematic and
will be the focus of our attention in the next subsection.

5.2 Infrastructure and Effective Computer Usage

     It is common for organizations to underinvest in
infrastructure, even training staff in the use of key
applications. We have seen organizations, especially university
departments, where clerical staff were given PCs, but not taught
how to use key software. Clement (1990) reports an interesting
case where some secretaries in a  university administrative
department did not know they were getting computers until they
actually arrived - surprise!.

     Few workers are rewarded explicitly for learning or using
computing; it is usually viewed as an adjunct to a job -- like a
telephone, FAX, or photocopier. Job performance is usually
evaluated in terms of the overall quality of goods and services
one produces, rather than the technologies used to produce them.
Computing applications vary in their complexity, and people vary
in the range of features they need to use. But it can easily take
a person 15-50 hours to learn about MSDOS and the good formatting
skills in a complex word processing package like Microsoft Word
or WordPerfect.

     Managers of professional groups often assume that many of
their staff will teach themselves the necessary computing skills.
And it is common for professionals to teach themselves some small
envelope of skills with specific software so that they can use
computing for some  key tasks. Clerks have a different work
ethos, since they are selected and trained to receive delegated
work rather than working on self-generated activity. While some
clerks have become self-starters in learning computing, clerical
groups sometimes languish in computing use without specific
training. In most cases, managers underestimate the time required
for staff to develop adequate skills. Weaknesses in the skill
levels at PPRO, for example, lead their secretarial staff to
gravitate to Macs over PCs because they were self-taught. (PPRO's
computing specialists preferred to maintain the minicomputer or
their statistical software rather than get deeply involved with
secretaries and their word processing.)

     The expected computing infrastructure can influence the
choice of an appropriate computing package. For example, in mid-
1987, I was interested in selecting a relational database for the
DCRP and was also asked to recommend such a database for an
office in the university administration staffed with non-
technical administrative analysts. Amongst other alternatives, I
evaluated Dbase III and Paradox 2.0. Dbase III was the market
leader, but it required programming to develop moderately complex
inquiries and to produce all but the simplest reports. In
contrast, Paradox could produce complex queries and all of its
reports from a menuing system, although it also had a programming
language.

     If the groups expected to develop complex custom
applications, and had funds to retain programmers to develop and
refine applications, then Dbase III would offer significant
advantage in finding programmers. If the groups had to develop
their own applications, and periodically devise their own
reports, then Paradox would be a more effective choice. In the
case of the administrative office, there were funds to buy
software, but no funds to hire a database programmer. In the case
of the DCRP, I did not want to devote significant funds from a
very limited budget to hiring a programmer. In both cases,
Paradox was the more workable alternative. This case is a simple
illustration where ignoring the actual infrastructure could have
lead to a poor choice. Dbase III was a market leader for many
good reasons, but not good for these groups.

     Decentralized computing has many costs that are not apparent
to central administrators (King and Kraemer, 1981). While the
purchase price of PC hardware and software can be relatively
affordable, there are many hidden costs for a variety of
activities associated with computer use. Many of these costs are
measured in the time such as training new staff, archiving files,
and upgrading and maintaining computing. They are frequently
difficult to quantify precisely.  With limited budget, a work
group has incentives to develop their own strategies for
balancing between the perceived costs of outside computer
services, the procurement costs for hardware and software used
within the group, and the time required to develop or improve in-
group computing capabilities.

     Providing resources for secretarial groups and helping them
establish such a support network has been shown to help these
groups become self-supporting computer users.  Clement (1990)
describes clerical work groups that were given such an
opportunity.  Administrators decided unilaterally to procure
microcomputers and require secretaries to use them.  Most of the
funds were spent on hardware and software, and training was
minimal. The secretaries were unhappy with their computing
infrastructure. They had to learn computing skills in the course
of their normal work and relied heavily on outside expertise.

Because of secretarial complaints to the unions and to the
administration, a special project, called the Self-Managed Office
Automation Project (SMOAP), was started to see if the office
workers could support their own computing needs (Clement, 1990).
By establishing a microcomputer resource center, which the
secretaries used for instruction, problem solving and as a center
for reference materials, the secretaries became self-supporting.
They were able to develop a support network of clerical users
that crossed departmental lines. Their evaluation of their
computing support infrastructure improved dramatically.  Through
the help of SMOAP, each group of secretaries moved from being
dependent on external expertise to developing their own
expertise.

     It would be no surprise if one found that people who were
not trained to use a particular computer systems didn't use it.
But the influence of infrastructure can be far reaching, even
when it is moire subtle. The case of group calendars is an
interesting illustration.

     Many system designers view information as a public good, one
that systems users are likely to share readily. This assumption
underlies the design of many computer conferencing systems, and
one emerging application, group calendars. The motive for group
calendars responds to professionals' common complaints about the
amount of time and number of phone calls they require to schedule
meetings with 3 or more participants. Certain popular commercial
offices systems, such as IBM's PROFS, DEC's All-in-One, and Data
General's CEO include group calendars. Some specialized systems,
such as Higgins and Right Hand Man, are built around calendars as
a core application.

     In a review of "workgroup productivity software," Derfler
(1989) argued that group scheduling or calendaring software was a
critical module," although other modules, such as text processing
and electronic mail, are important to make a more usable system.
He went on to say:

          Scheduling three or more busy people for a
     meeting, along with arranging for a conference room and
     a slide projector, can be a frustrating and
     time-consuming task, requiring at least three phone
     calls. If one person or facility isn't available at the
     time the other people or facilities are, a whole series
     of negotiations begins. Mathematicians refer to it as
     progressive approximation; you (or your secretary
     making the arrangements) call it frustration. Before
     the scheduling problem is resolved, the number of
     people involved and phone calls made may have increased
     dramatically.

     Scheduling programs ... vary in how they confirm
     proposed events. The simpler packages assume that if
     the event fits on the calendar, that the people
     scheduled to attend will be there. Other programs ask
     for confirmation, while some go as far as to tie into
     electronic mail modules for notification.

     .... The best scheduling software is utterly useless if
     people aren't willing to play the game by keeping their
     personal calendars current. Obviously, these personal
     calendars are at the heart of the group scheduling
     process-- calendars that aren't readily available or
     easy to use will never be maintained by group
     participants. With this in mind, it seems imperative
     that these programs allow you to run the personal
     calendar module (interactively while running other
     programs) and make it easy to use (Derfler, 1989:248).

     Derfler describes and critically evaluates key features of
some major programs, and describes the best of these packages as
dreams come true for busy professionals and managers. He
describes how these programs can facilitate various kids of group
activities, such as scheduling, under the best of conditions:
machines are up and running properly; people have immediate
access to the shared system to keep their calendars up-to-date;
people actually keep their calendars up-to-date. Unfortunately,
he does not explain what social conditions make these packages
most effective -- or even usable at all.

     Recent empirical organizational research on the use of
groupware shows that group calendars are rarely used for
scheduling meetings (Bullen and Bennett, 1991). The conventional
explanation focuses on the interface designs, and critiques
calendars whose use requires alot of additional work -- clumsy
systems, systems which have different conventions than the
professionals' primary applications, and the work effort
sometimes required to leave one's primary application to jump to
a calendar. These criticisms can all be resolved by improved
software designs.

     Grudin (1989) asks a more fundamental question: how valid is
the model of information processing as a public good which is
implicit in group calendars? Grudin observes that managers, who
have good secretarial support, are more likely schedule meetings
than are professionals who rarely have dedicated secretaries. In
this common set of cases, the "political economy of effort" to
keep calendars up-to-date works to the advantage of managers (low
cost). But it imposes relatively high demands on professionals
who do not have comparable assistance (infrastructure) to keep
their calendars current. While interface improvements can reduce
the costs, the way that people who are out of their office may
(managers) or may not (professionals) be able to phone in
calendar changes plays a more fundamental role in the information
economy and subsequent workability of such systems.

5.3 Negotiations Around Production Lattices

     It would be analytically attractive if we could apply
discrete-entity models to help understand the kinds of
infrastructural resources which are available to participants who
develop, integrate, and use computer-based systems.  However the
way that production lattices are layered and often cut across
organizational units usually makes discrete-entity analyses too
weak.

     The natural open systems organization models helps us
understand variations in the kinds of resources which are (or
could be) available to different parties.  Discrete-entity models
lack the conceptual richness to easily explain phenomena such as
these:

a.   When some computing resources are shared by several
     participants (e.g., individuals, organizational subunits,
     coalitions), service will often be differentially provided,
     and more powerful participants will often receive better
     levels of service where the provider has discretion.  For
     example, PPRO's office staff were responsive to the
     director's preferences for using Microsoft Word, but were
     unwilling to inconvenience themselves by acquiring a word
     processing format conversion package to help work more
     effectively with research staff who found Microsoft Word to
     be technically unattractive.

b.   Computing resources may be selected so as to improve the
     negotiating posture of service providers in conflicts which
     are defined at larger scales of action than a particular
     bundle of computer services. For example, we studied a
     multi-divisional engineering firm in which the primary
     division used mainframes supplied by a major computer
     vendor. Another division of the firm chose a different
     primary vendor, so they would have a plausible rationale to
     acquire or develop their own (incompatible) software.
     Otherwise, their engineers might have to accept software
     chosen by the primary division.

c.   Resources may be selected in line with social meanings
     defined in larger social worlds in which some key actors
     participate.  For example, systems programmers and facility
     managers may have special preferences for equipment
     identified with specific vendors (e.g., IBM, DEC, Apple) of
     technological standards (e.g., Unix, MSDOS).  When
     performance criteria are ambiguous, social definitions may
     dominate decisions about adoption.

d.   Sometimes there are conflicts between the kinds of
     computer-based service a consumer desires and what a
     provider sees as his line of work or the going concern of
     his organization.  A common, relatively individualistic
     example is the difficulty many managers and users find in
     having programmers adequately document their software.
     Programmers receive many rewards -- both psychological and
     in their careers -- for writing programs.  Documentation is
     not their line of work, and does little to advance a
     programmer's career on the job market.

     In each of these four kinds of situations, the computing
resources and the services provided are probably "sub-optimal"
based on narrow considerations of task.  The resources selected
are based in part on negotiations which take place in social
settings defined by boundaries that extend well beyond the focal
computing resource and its immediate users.

     Negotiations matter in practice.  Technical efficiency
analyses only explain a fraction of the kinds of choices
organizational participants make when selecting or providing
computer-based resources.  Moreover, today's structural
arrangements (e.g., routines for allocating computing resources)
are often the byproduct of battles or negotiations worked out
previously.

5.4  History of Computing-related Commitments

     Over time, key actors developed an array of infrastructural
resources to support their computer applications.
Discrete-entity analysts usually take these resources for
granted.  Web analysts view existing arrangements as embodying a
complex set of commitments made earlier.  Some of these
commitments are particular to computing (e.g., the kind of
equipment in use).  Others are defined in larger settings within
and without the organization (e.g., hiring procedures,
procurement procedures).

     Few published studies of computing arrangements carefully
trace the way that commitments made over long time periods
influence the use of a computer application, how its
constituencies shape and adapt it, etc.  The studies that examine
historically derived commitments usually focus on periods of a
few years (Kling, 1978b; Markus, 1984; Dutton, 1981, Kling and
Iacono, 1984b; Jewett and Kling, 1991) although longer periods
are sometimes examined to provide "context" (Laudon, 1974; Laudon
and Laudon, 1988:879-896).

     Organizations develop infrastructures for computing support
over months and years -- the routines, the equipment selected,
the expertise developed in different subunits, the meanings and
ideologies developed to justify them, etc.  These are not easily
altered when troubles arise.  In general, infrastructures are
developed incrementally, rather than by large and swift changes.
Discrete entity analysts try to identify the problems of computer
use by focusing on specific procedures or equipment. If one views
infrastructure as a product of short-term organization building,
then it should be easy to change when needed.  Web analysts are
usually less sanguine that infrastructures can be rapidly created
or altered by simple administrative will.

     Any analyst of computing developments tacitly selects a
temporal frame in which to situate his account.  Discrete entity
analysts rarely begin their accounts before the initiation of the
focal computing resource.  Such historical frames are often too
limited to help explain the kinds of constraints faced by key
actors in the local saga of computing.

     For example, consider the DCRP's replacement of PC-Write 2.7
with  WordPerfect 5.0 as the staff's primary word processor in
mid-1988. A discrete entity analysis would examine the
corresponding features of PC-Write, WordPerfect and other
alternatives, such as MS-Word and Emacs+Tex. The analysis would
match their features to the kinds of documents produced by the
DCRP. Such an analysis would miss key contingencies and overvalue
others. The ICS faculty and support staff had a commitment to
EMACS and Tex that went back over 5 years, but there was no
formal training for Tex. Tex was relatively complex and the
manuals were written primarily for programmers. Further, the DCRP
did not have computers or software which would allow the staff to
readily preview documents in Tex. The choice of Tex would have
facilitated the use of ICS' Imagen laser printers, but would have
imposed relatively large training and operations costs. In fact,
the consideration of WordPerfect was an attempt to gain some of
the laser printing advantages of Tex with lower costs of learning
and use.

     The PPRO staff was committed to MS-Word for over 3 years.
They were also moving from PCs to Macs, partly to provide new
graphics services, and partly to offset their own poor training
with PCs. In 1988, MS-Word was the only word processor which
worked well on both Macs and PCs. PPRO's and ICS' text processing
arrangements were highly institutionalized and their staffs had
little incentive to change to newer software, like WordPerfect
5.x.

     The DCRP staff could choose the same word processors as were
used by either ICS or PPRO. The print quality standards in DCRP's
the research world had shifted rapidly so that laser printing
(rather than dot matrix printing) was relatively standard.

     Further, space arrangements at PPRO were stable since 1982,
and also institutionalized. The DCRP did not have sufficient
space at PPRO for the PI and RAs to have quiet space, despite
continuing requests to PPRO's managers. The PI and RAs often
worked at home when they were writing papers and most likely to
want laser printing services. WordPerfect's ability to allow
users to preview the formatting of laser printed documents, and
then to send the documents over communication lines to ICS
offered outstanding advantages. These outweighed the advantages
of working with PPRO's standard (MS-Word). Since the PI still
used ICS facilities for printing administrative and teaching
materials, and the ICS RA's used ICS for printing course papers,
the solution to match PPRO would not have been a strong overall
solution for them. The DCRP PI's selection of WordPerfect over
MS-Word, however, increased the negotiating costs between the
DCRP and PPRO's administrative staff. It also increased his
workload at ICS, since his secretary was trained to use Tex. But
the ICS Department Chair refused to give him secretarial support
for using PC packages, like WordPerfect.