Metamorphosis in Computing Services at Indiana University


Copyright 1992 CAUSE From _CAUSE/EFFECT_ Volume 15, Number 1, Spring 
1992. Permission to copy or disseminate all or part of this material is 
granted provided that the copies are not made or distributed for 
commercial advantage, the CAUSE copyright and its date appear,and notice 
is given that copying is by permission of CAUSE, the association for 
managing and using information resources in higher education. To 
disseminate otherwise, or to republish, requires written permission.For 
further information, contact CAUSE, 4840 Pearl East Circle, Suite 302E, 
Boulder, CO 80301, 303-449-4430, e-mail info@CAUSE.colorado.edu


          METAMORPHOSIS IN COMPUTING SERVICES AT INDIANA UNIVERSITY
                by Polley Ann McClure and James G. Williams

************************************************************************

Polley Ann McClure has been Associate Vice President for Information
Resources at Indiana University since July 1991. In this role she is
responsible for leadership, planning, policy, and coordination in the
areas of computing, printing, voice, video, and data at IU's eight
campuses. Previously, McClure was dean and executive director of
Bloomington Academic Computing Services, overseeing in that role its
merger with the University's administrative computing unit into
University Computing Services.

James G. Williams has been Associate Director for Network Systems with
University Computing Services of Indiana University since October 1989.
He is responsible for planning, development, and maintenance of the
University's data networks, for local area network services, and for
other aspects of network information and service delivery. Williams was
previously manager of networks and workstations with Bloomington
Academic Computing Services. He holds BS and MS degrees from Michigan
State University.

************************************************************************

ABSTRACT: As information technology advances, universities, colleges, 
and other information-intensive enterprises periodically discover that 
their technology support structures no longer meet their institutional 
needs. In 1988 Indiana University's separate academic and administrative
computing units were failing to respond to computer users' changing
demands. In merging and reorganizing these units we tackled problems
shared by many similar institutions. In the process we learned much that
will both encourage and forewarn others whose need for structural change
in their technology service units is only now becoming clear.


The 1990s dawned over information resource managers within higher
education with a shocking new message: The rate of increase in demand
for their basic services will be at least as great as during the 80s,
but budgetary resources to meet those demands will at best remain
constant. During the 80s higher education costs increased by an average
of 10 percent per year, and information technology's percentage of the
total budget rose from 2.5 percent to more than 3 percent. At Indiana,
demand for services ranging from availability of public computer
facilities to MIPS-hours of UNIX cycles increases at rates from 20
percent to well over 500 percent per year. One grand challenge of the
new decade is how to deliver more services to more users each year with
less and less funding.

This development comes at a time when the rate of change in the
technologies we are implementing and managing is at an all-time high.
Printing, duplicating, copying, and fax technologies are converging.
Users are demanding access to the world of electronic information
through a single, transparent network. Everyone wants the mainframe
systems and data they have developed over a decade, through an
investment of literally millions of dollars, to suddenly appear local to
their desktops. And the demand for multiple media, integrated at those
desktops and accommodated within our networks, is not far behind.

Complicating these challenges at many colleges and universities are
organizational structures more suited to the 60s than the 90s. Some
examples:

  *  To grow, computing technology needs networks. But networks at many
institutions are controlled by the campus telephone "utility," whose
approach to data communications may not be in synch with the needs of
network technologies.

  *  Most academic information content is the purview of campus
libraries. Increasingly, libraries need computers and networks to
deliver content to their patrons. Often, they must work within the
framework of information access technologies and policies that are ill-
suited to the delivery of scholarly information.

  *  Administrative information is often centrally controlled by a data
processing organization whose priorities may be in conflict with the
connectivity needs and user interface expectations of those who use the
information.

There are many tools that college and university administrators can use
to cope with the exploding technology demands of the 90s. The tool
Indiana chose, and the one we discuss here, was structural change in the
University's technology organizations.

In 1988, Indiana University's administration decided to merge its
two largest technology service organizations to improve services and
contain future increases in operating budgets. In this article we
describe the environment that led to this decision, the process we used
to carry out the merger and reorganization, and the early results of
that activity. While the specifics of our experience relate to Indiana
University, we think our concerns and experiences are relevant to higher
education in general.


THE ENVIRONMENT AT INDIANA IN 1988

Indiana University is one of the oldest state universities in the
Midwest. It was founded in 1820, only four years after Indiana achieved
statehood. It has grown to include eight campuses. The large campuses at
Bloomington and Indianapolis host two-thirds of the University's
students; smaller campuses serve Fort Wayne, Gary, Kokomo, New Albany,
Richmond, and South Bend. With a total enrollment of nearly 94,000,
Indiana University ranks as one of the largest institutions of higher
education in the United States.

In 1988 information technology needs at Indiana were served
primarily by each campus, though all administrative computing and some
media services were provided centrally. A central dean for academic
computing coordinated research and instructional computing services
systemwide, and the director of telecommunications provided central
support to campus communications departments. Library services,
likewise, were the responsibility of each campus, with coordination
provided by the dean for University Libraries, who also headed the main
library in Bloomington.

Administrative computing was built around transaction processing on
a core of IBM mainframe technology, with a 1,400-node SNA network
spanning the state. Academic computing was provided through a variety of
DEC, IBM, PRIME, and microcomputer hardware on individual campuses.
Virtually all of these resources were linked systemwide through
asynchronous networks.

The SNA and asynchronous networks, however, were not connected. The
result was that users could only access services or information stored
on computers on "their" network. Major upset among faculty had resulted
from the libraries' 1983 announcement of plans to use the administrative
IBM mainframe and SNA network to develop the library automation system
and public access catalog.

The reporting lines of key administrators in information technology
followed entirely different paths: administrative computing and
telecommunications reported to the vice president for finance; through
an Office of Information Technology, the dean for academic computing
reported to the Bloomington vice president; the dean for University
Libraries reported to the Bloomington vice president and to the
president. Others reported to campus chancellors.


THE RATIONALE FOR MERGER

Three problems confronted information technology managers in 1988. Their
resolution was critical to progress in harnessing the increasing power
and efficiency made possible by technological advancement. They were:

  *  the evolution and convergence of technologies then administered by
different organizations,

  *  significant unmet institutional needs for information resources,
and

  *  unproductive tensions among the information technology service
units.

After expanding on each of the problems listed above we will describe
the solutions that Indiana adopted.

Evolution and convergence of technology

The personal workstation becomes a ubiquitous tool. Before the era
of the personal computer, terminals were the common online data entry
devices. Functionally, terminals were integral parts of the mainframe
systems to which they were attached. They tended to be optimizedto work
with certain mainframe hardware, and, at Indiana at least, the terminals
used for administrative computing and academic computing, like the
systems they accessed, were completely incompatible.

The emergence of the microcomputer as a serious personal tool for
working with information led the list of technological factors favoring
convergence of academic and administrative computing functions. Academic
and administrative offices alike developed voracious appetites for the
same desktop productivity tools--word processing, spreadsheets, database
or file management utilities--and both computing organizations struggled
to provide support. Unlike the two organizations' mainframe and
timeshared applications, which differed very significantly between most
administrative and academic functions, these personal computer
applications did not.

Electronic mail and conferencing emerge. In the early 80s
electronic messaging software became available for most timeshared
computers. Its use increased in direct proportion to the extent of the
network connecting users to their timeshared computers and the
availability of terminals in individual offices. At Indiana, these
applications were available to users of the separate administrative and
academic mainframe systems. Despite their enormous popularity, the
versions of these tools on the administrative and academic mainframes
were completely incompatible and could not intercommunicate, isolating
the two halves of the institution. Neither set of users wanted to give
up its favorite mail system and neither computing organization wanted to
force its user base to change.

Academic information goes online as an institutional resource.
During the 70s corporate America realized that business information was
a powerful institutional resource, and the organization and function of
its data processing organizations evolved accordingly. Colleges and
universities, too, recognized the growing importance of information
resource management within their administrative computing organizations.
But there were significant differences between the "business" of
administrative and academic computing that kept academic computing
focused upon technology rather than information. Prior to the 80s most
academic computing organizations thought of themselves as being in the
"cycle delivery" business.

Academically important databases such as LEXIS, NEXIS, DIALOG, and
BRS became increasingly available in the late 80s. The systems through
which they were delivered and supported more closely resembled the
transaction processing systems in the administrative data processing
center than the "raw computers" in the academic center. This, coupled
with the management philosophy and focus on operational control common
in administrative data centers, made them the logical hosts for these
academic "production systems."

During this same period, the processing capability of desktop
computers and departmentally owned systems was increasing rapidly. It
became clear that much of the "computing" demand of faculty and students
could be met effectively with small, decentralized computing resources.
Economies of scale reversed themselves and much of academic computing
could be more cost-effectively performed outside the computer center.
Academics began to focus on the academic computing center as the logical
source for shared data such as census data and bibliographic databases.

Thus, both academic and administrative computing centers found
themselves pressured to provide mainframe capacity to manage and deliver
overlapping sets of institutionally owned shared information.

Internetworking technology emerges. Prior to the late 80s,
communications technology was closely linked to computing technology.
Most computing vendors developed and promoted proprietary operating
systems that required specific, proprietary communication hardware and
protocols. Within many institutions this had led to the existence of at
least two completely separate networks. The emergence of internetworking
technologies based upon the open TCP/IP protocols presented, for the
first time, the opportunity to create a single network to serve all
users.

Significant unmet institutional needs for
information resources

Despite the existence of two very good, mature computing
organizations, and substantial investments in technology, both academic
and administrative users at Indiana were dissatisfied with their
information resource environments.

Administrative users acknowledged that they had a stable and
reliable computing environment and that the available transaction
processing systems were efficient and of high quality. The
administrative network was secure and reliable and met their transaction
processing needs. Response time was good. They had direct access to
institutional data, but wanted that access to be easier and more
flexible; they knew that a formal data administration framework was
needed. These same users wanted more responsive leadership from the
administrative computing center and more involvement in planning and
technology decisions. Staff in many of the administrative departments
were skilled programmers and they wanted more direct involvement in
systems development. They felt that decision-making about administrative
systems was overly politicized.

Academic users had, historically, not been charged for most of
their central computer usage. They were very protective of these "free"
computing resources, with which they met much of their need for general
purpose computing. At the same time, academic users were crying for more
capacity for research needs and for greater stability on central
academic systems and faster response time. Exploding user support needs
had stripped many of the academic computing center staff from "hard
core" technical areas, and users perceived a lack of technical depth
among computer center staff.

Academic users wanted "their" network to provide access to the
automated library catalog and to institutional data on the
administrative mainframe. Academic administrators and faculty felt that
administrative computing priorities were unresponsive to the needs of
academic departments, faculty, and students.

PC- and Macintosh-based instructional environments were being
developed. By the late 80s most personal workstations used in the
sciences, at least, were being connected to a coaxial cable-based
Ethernet backbone over which their owners could access local timeshared
academic systems and external networks (through what was then ARPAnet).

Unproductive tensions among the information technology service units

The late 80s were a time of changing roles and significant tensions
among the agencies responsible for academic and administrative
computing, media (audio/visual) services, and the libraries at many
institutions of higher education. Many of the tensions resulted from the
convergence of academic and administrative computing and networking
technologies, and from the increasing role of computing and electronic
information in the function of the libraries. They resulted as well from
the diffused responsibility among college and university administrations
and from their inability to resolve conflict among key, powerful units
such as the libraries, administrative and academic computing
organizations, and media services units.

Traditional rivalries between academic and administrative computing
organizations exist at many institutions. At some (as was the case at
Indiana), these rivalries go beyond constructive competition, and can
hold back progress that would be of significant value to the
institution.

Why do these problems exist? At Indiana, the charters of the
individual service agencies had become unclear, having failed to keep up
with the evolution of technology. The organization of the two units did
not allow effective updating of their charters or easy resolution of
disputes. Putting aside the independent authority exercised by each
campus over its own academic computing,the four principal central
information agencies--academic computing in Bloomington, administrative
computing, media services, and the libraries--were under the control of
three different executive offices. The directors of the individual units
were intense, committed, and ambitious people who wanted to further
their own (very different) models of technology within the institution.
This problem was made more difficult by the lack of direct interest
taken in the role of technology by the executive management of the
University, and its failure to attend in a unified and consistent way to
the problems that were developing.

At many schools, as the technologies underlying academic and
administrative computing have converged, traditional understandings
about which organization is (or should be) responsible for specific
functions have become less and less useful. In some cases,
responsibility is to be allocated on the basis of whether the office
needing service is an administrative department or an academic
department. Other times, responsibility is allocated application by
application, regardless of the user's departmental affiliation. At
Indiana, for example, it was unclear who should be responsible for
electronic mail. Was it an administrative or academic function? Should
users of the academic computers be required to shift to the
administrative mainframe for their e-mail? The campus-wide information
system is another example. It was developed on the academic VAXcluster;
how were administrative mainframe users to access it? The two computing
organizations at Indiana attempted to work out these questions primarily
by competitive means. This resulted in duplication, failure by both
service agencies to respond to certain service opportunities, a less
than optimal match between resources and services, and working
relationships that were not always cooperative.

A common example of duplication in services between computing
support units at a given institution is in the development of
independent electronic mail systems to serve users of the separate
academic and administrative systems. Many institutions have failed to
bridge these mail systems until user demand has overpowered their
insular instincts. At Indiana, our two computer centers disagreed over
the nature of the connection between their two, disparate networks, and
over issues of control related to that connection. While adoption of a
single networking standard could have solved this problem, we doubt that
an agreement of such overarching impact could have been reached in the
political climate that prevailed.

Issues of control are rooted deep in the traditionally separate
authority of "academics" and "administrators" within higher education.
Directors of both types of computer centers have constituencies that
understand well the growing importance of the network to their efforts.
But typically neither set of constituents trusts the other to make
decisions in its interest. Often there are no perfect technological
solutions to the problems of integrating two networks, and the two sets
of constituencies typically put different weight on the importance of
access versus security. At Indiana, our two organizations used
completely different funding models for their separate networks, so
concerns over control also had a real basis in problems of financing and
charging. Struggles like this are usually clothed in discussions about
functionality and service level and security. But underlying most of
them are basic conflicts about control.

At Indiana, perhaps the most obvious example of the impact of
unclear charters came about as a result of library automation. Our
library automation effort lagged behind those of our peer institutions
partly because of the very large collections at Indiana and the startup
costs of electronic cataloging. But an equally important cause was the
unclear authority for decisions about the software that would be used,
and the consequent struggles between the administrative computing
organization and the libraries. These struggles were eventually resolved
when the directors of both organizations left the University within six
months of each other!

Why were these agencies unable to revise their charters in light of
the evolution of technology and the obvious problems created by failure
to adapt? In part the answer undoubtedly lies with the individual
directors and their inability to rise out of their competitive deadlock
to find resolution. And, in part, the reason lies in the organizational
structure of the University. There was no joint intersection of these
directors' reporting lines below the office of the president, and thus
no office with responsibility to assist in conflict resolution. During
the 80s we made several attempts to correct this structural problem; all
failed because the solutions were incomplete.

Finally, as at many universities, the Indiana University of the 80s
was characterized by tension and mistrust between the institution's
administration and its academicians. In that climate, the independent
reporting lines of the information service units and the University's
failure to align budget and reporting relationships allowed the
differences growing out of technology, culture, and personalities to
persist and work their destruction. In this situation, the leadership
for a solution needed to come from the president working with the vice
presidents and chancellors of the University.


PROCESS

By January 1989 many of the sources of our difficulties had become clear
to us. As the University administration changed and became receptive to
restructuring, we began a process of merging and reorganizing academic
and administrative computing. Intimately combined with this process was
a strategic planning initiative involving the entire management staff of
both organizations.

Our first step was to determine the services the new organization
should perform. From the definition of services we then determined the
technology architecture we would need and the support requirements it
implied. The technologies and support needs then dictated the
organizational structure.

The main process took about 18 months. We set up an interim
management structure in which the associate directors from the two
former organizations continued to run their divisions, but all reported
to the new executive director. The two organizations operated as a
grafted-together whole for about a year while the planning process was
completed. In a series of weekly operational meetings we made most of
the important organization-wide decisions. While acting as interim
managers, the associate directors and executive director formed a core
planning team. Most of the reorganizing work of this group took place
during after-hours "pizza meetings."

We defined the University's service needs through very extensive
interactions with user groups, advisory committees, and individual
conversations with members of the University community. Two landmark
papers, "Needs for Administrative Computing at IU" and "The Future of
Academic Computing at Indiana University," were prepared by
administrative and academic leaders at the institution and formed the
basis upon which all further planning took place. The definitions of
technology architecture, support requirements, and, ultimately,
organizational structure were largely accomplished by the members of the
planning group. Their ideas were captured in a series of white papers.
These papers were discussed in draft form with staff, users, advisory
groups, other campus technology units, and administrators, and were
revised accordingly. They formed the theoretical basis for the new
organizational structure and its service offerings.

Staffing the new organization

Once the organization structure was determined, all of the new unit
head positions were declared open, and a national search was launched.
Most of the associate directors of the two former organizations applied
for one or more of these positions. Two former associate directors were
chosen to fill new positions. Three positions were filled by individuals
previously at different levels in the old organizations. And one person
was hired from outside. As soon as new associate directors were named,
they began the process of internal organization of their own divisions,
sharing plans with each other in weekly senior management meetings.

During the eighteen months of planning a soft hiring freeze was
imposed on both organizations. Only absolutely critical positions were
filled when they became vacant. This resulted in a pool of about thirty
vacant positions which provided essential flexibility in staffing the
new units. Once all associate directors had developed skeletal plans for
their units, we shared tentative requests for numbers of staff
positions. The total number of staff requested exceeded the combined
staffs of the two former organizations by a factor of at least two! A
consensus-based process was used to reduce the total number of requests
to the number of positions available. If we had desired to reduce staff,
we could have done so at this time.

Employees were assigned to the allocated positions in two phases.
In the first phase, about 85 percent of the positions had an incumbent
who was the obvious person to continue doing the job. Those placements
were simply made by consensus. Many of the remaining positions were in
new areas. Among the unallocated staff were our "stars" who were hotly
contested by more than one associate director to fill different
positions. A one-week recruiting period was set aside and each associate
director did her/his best to recruit these individuals. At the end of
the period, we assigned these people to the units/positions of their
preference.

At the end of eighteen months, new units were formed, their staffs
were in place, and internal management groups were operating and had
developed tentative operational plans for the next year's objectives,
following the overall UCS strategic plan.

Our merger was characterized by management participation and
consensus-building. This may seem excessive to some, and in some
circumstances could be a mistake. In our case, however, we believe the
investment was a key to our success. The two merged organizations were
very different in culture, technology, management style, economy, and so
forth. We knew we needed to forge new definitions for all of these
dimensions. Through an "overnight" reorganization we could have
physically reassigned people, but that would have ignored these softer
organizational dimensions. We understood that time and interaction would
be required to bring about real change. We also believed that these
organizational changes would not be the last that we and other service
units at Indiana would ever undertake. We took the time to build into
our own people an acceptance of organizational change, and tried to
position this change as a positive model for similar processes to take
place in other units. Making our merger a positive, participative
experience went a long way in accomplishing that.


OUTCOMES

The old academic computing organization was called Bloomington Academic
Computing Services (BACS). It consisted of three units: Computing
Systems, Support Services, and Network Services. BACS reported to the
academic computing dean.

The old administrative computing organization was called
Information Systems (IS). It too consisted of three units: Central
Systems and Networks, Information Systems, and Finance. IS reported to
its own director.

The organization structure of University Computing Services (UCS)
is represented in Figure 1. Six separate units were created within the
new organization. The Support Systems unit provides the initial
interface from the computing organizations to our academic and
administrative clients. It was designed to be very broad but somewhat
thin, offering limited expertise over a wide variety of technologies.

[FIGURE 1 NOT AVAILABLE IN ASCII TEXT VERSION]

The four technology units, Network Systems, Computing Systems,
Workstation Systems, and Information Systems, all "support" the Support
Systems unit. Figure 1 portrays our vision of these separate units. They
were designed to be narrow in focus and deep in expertise, providing the
University with badly needed resource persons in key areas of
technology. We discuss the structure of the technology units in more
detail below.

These five units of the organization are supported by the
Management and Administration (M&A) unit, which provides essential
budgetary, financial, planning, and documentation services for the
entire new University Computing Services organization. M&A in turn
provides the UCS organizational interface to the University's financial
and human resources service organizations.

A new structure for technology

Neither BACS nor IS was optimally structured to deal with current
computing technology. Each paid too much organizational attention to
mainframe computing, too little to networks, and nearly none to
workstations. The idea of distributed computing was unfamiliar to both
organizations, largely because it was inappropriate to the
organizations' existing technology structures.

One early outcome of the reorganization into UCS was our
development of two new technology units, Network Systems and Workstation
Systems. The new network unit contained many of the staff from the old
BACS and IS organizations who had performed network functions. It
centralized them, and gave them a distinct identity and role in a unit
that was the organizational peer of the mainframe computing unit
(Computing Systems). By contrast, the workstation unit was created from
scratch, its positions attracting candidates from BACS and IS, other
University departments, and elsewhere across the nation. Again, the
formation of a separate workstation unit gave that technology a status
equal to mainframe computing.

These two restructurings of technology within UCS led to our
development of a distributed computing architecture, which provided an
entirely new way of thinking about computing at Indiana. To host
research and development projects in distributed computing, UCS
established in 1991 a Program for Distributed Computing (PDC). Embracing
talented programmers from across the organization, PDC has forged
effective cross-linkages among the Network Systems, Workstation Systems,
Information Systems, and Computing Systems units.

The newly formed Computing Systems unit took on management of the
organization's central computing resources, as well as those of several
client departments. The Information Systems unit handles the development
of end-user applications within UCS and for many client departments and
is responsible for information access and the increasingly important
data administration function. These two groups, along with Network
Systems and Workstation Systems, make up the four technology units in
the UCS organizational structure.

Lively discussions among all four technology units, combined with
key elements of our strategic plan, established a set of preliminary
technology standards for the University, users, and other campuses.
These general standards gave the technology groups an initial blueprint
for their investigation and evaluation of information technologies. The
standards were also used by the Support Systems staff of the
organization as they consulted with computer users on their particular
technology problems and questions.

To ensure that the evaluation of technology would continue, all
four technology units established a formal mechanism for technology
standards and planning. To ensure the transfer of technical know-how to
Support Systems staff, the technology units provide a continuing series
of "support training seminars." These seminars directly expose key
support staff to developments in technology through presentations by
technology unit members.

A new structure for support

Both BACS and IS offered several forms of support, but each
supported only its own machines, applications, and clients. If you were
a faculty member and happened to use MultiMate, the IS-supported word
processor, you couldn't ask BACS for support: they could not help you.
Similarly, IS could not support WordPerfect, the word processor
supported by BACS. Each organization was attentive to support of its own
products; neither was attentive enough to supporting the work of faculty
and staff.

Also, the basic support models followed by the two organizations
were quite different. IS had "departmental liaison" staff, each member
of which worked closely with a small number of administrative
departments, handling many aspects of departmental computing, typically
at the level of hardware selection and configuration or software
application design. These interactions generally led to billable
activities such as equipment setup or application development.

The academic support model, by contrast, consisted of a central
support desk that faculty and staff could call with questions, and a
number of staffed public computing facilities that took walk-in
consultations. If the user's question required a "house call," it
usually resulted in a bill to the user.

Support personnel from both organizations were combined into the
new UCS Support Systems unit. To capitalize on the staff's diversity of
experience and knowledge, and to encourage the breakdown of the
academic/administrative schism in service orientation, we undertook a
purposeful mingling of academic and administrative personnel.

We designed the present UCS support services around the most
effective parts of the old organizations' offerings. The BACS call-in
support function mentioned above was expanded to include support for
administrative equipment and applications. The departmental liaison
program was broadened to include academic departments and was renamed
Departmental Consulting.

Rapid expansion in use of technology at Indiana has strained the
resources of the UCS Support Systems unit. Even with merged staffs and a
unified focus, the unit is unable to offer the support that departments
require. Because of its new, unified focus, however, the support unit
has been able to adopt a novel solution to the black hole support
represents: the Distributed Support Program (DSP).

The rationale behind DSP is to seed individual departments with
internal support providers. UCS dedicates a part-time computer
consultant to a participating department or group of departments. A
unified support structure allows a single consultant to meet all the
academic and administrative support needs of the client group.

UCS pays the consultant's salary for the first year, allowing the
department to make an informed decision about the value, or lack of
value, of an internal support person. If the initial year is successful,
the department and UCS each pay half of the consultant's salary in the
second year. In the third year the costs are totally the responsibility
of the department. This phased assumption of costs gives the department
an opportunity to adjust its budget gradually to the consultant's
impact.


ASSESSMENT

Three years have now passed since we merged our computing centers, and
we have had ample opportunity to assess the experience. Though the
undertaking was not without problems, we judge the merger a success, and
if we had it to do over we would surely do it again (though we would do
some things differently).

Problems

Three very clear problems have emerged from the reorganization. We
have solved portions of each, but all still plague us to some degree.

The first was a constriction in the flow of information between the
technology units and the Support Systems unit. Everyone in the
technology units agreed that they were, as a group, the experts on
technology issues. The Support Systems unit, however, had chronic
problems determining exactly who in each technology unit was the expert
for a particular technology issue. We have reduced the scope of this
problem somewhat through the publicized designation of a technical
support person for each major application area. Nevertheless, finding an
owner for a given problem can still be difficult.

Our second problem was the failure of the new organization to
respond consistently and effectively to our users' needs. The user
community, as well as many UCS staff, viewed the combined organization
as less responsive than BACS and IS had been. We have identified two
primary causes for this problem. One is the division of the organization
into six separate units (discussed in more detail in the next
paragraph). The second cause was our lack of clear internal processes
for handling routine service requests in the merged organization. It was
clear to staff that the traditional IS and BACS procedures no longer fit
the organizational structure. But we failed to develop a set of standard
UCS procedures early in the merger. As a consequence, the routine
business of the organization suffered.

The third major problem following the merger involved projects that
required the participation of two or more UCS units. The development of
six separate units for technology, support, and administration worked
extremely well in establishing deep technical knowledge within each of
the technology units. However, this focus on separate elements of
technology led many staff (at all levels) to identify more with their
units than with the organization. Too often this translated into cross-
unit projects receiving significantly lower priority than intra-unit
projects, regardless of the true institutional significance of the
activity. We continue to struggle with this particularly troublesome
issue. The problem is compounded by a simple logistic factor: the
organization is now very large. The University offers no quarters large
enough to house us all, so we are scattered among four buildings an
average of .9 miles apart.

Successes

One goal of our merger was to create a stronger, more unified
technical organization. In this area the organizational restructuring
has served us very well. Under the previous structure, for example,
staff within the administrative computing organization and in several
offices of the academic organization supplied the campus with advice on
the configuration and design of local area networks. Their
recommendations spanned a wide range of technologies, frequently
blatantly contradicted each other, and were of varying quality. Within
the merged computing organization we now have a staff of five people in
the local area network support group. We support a single local area
network architecture, Novell NetWare, and all five of the staff are
Novell Certified NetWare Engineers. While the previous, scattered groups
of individuals partially supported between ten and twenty campus LANs,
these engineers support over seventy and have become recognized as the
authoritative source for campus LAN information. In many of our units we
have developed similar deep understandings of computer and network
technologies and their roles in the evolving information environment at
Indiana.

Another goal of the reorganization was to better apply technology
to the daily business of the University. One project the new
organization undertook was the Administrative Workstation Project (AWP).
The essence of this effort was to take a group of twenty high-level,
traditional administrative users of the SNA terminal network and expose
them to the full range of distributed/networked computing. This group
was given desktop workstations, access to a file server, and detailed,
personal instruction in the use of a variety of software packages. The
project was designed to be evaluated along several dimensions, including
the administrators' acceptance of the technology, their productivity
gains, and their leadership in introducing fellow administrators to a
new way of doing the University's business. After its first year, the
project was viewed by the participants and the University as a major
success.

Although not a direct goal of the merger, a positive result was the
opportunity to totally re-think and re-examine how computing is
delivered at IU. Merging the academic and administrative computing
organizations was a radical change, and naturally caused us to rethink
the entire structure of computing at Indiana. We not only rethought the
broad organizational context of computing within the University, but we
rethought the individual services that were delivered to end users by
the two organizations. This pointed out inefficient staffing in such
areas as local area networks, in which we had three groups offering
essentially similar services, and network operations, in which two
groups offered overlapping services. It pointed out new areas in which
the organization needed to provide emphasis, such as data
administration, access to institutional data, and workstation computing.
The rethinking also pointed out areas in which UCS could decrease
emphasis, such as the traditional applications development area.

Another direct result of this rethinking was the development of a
distributed computing architecture for Indiana University. The
architecture documentation outlines what distributed computing
technology will mean to the computing environment at Indiana and is the
basis of a structured plan for implementing key elements of this
technology.

One of the critical institutional projects that led to the merger
of the organizations was the Library Automation Project. Indiana was not
in the forefront of library automation. Our library automation projects
had experienced false starts previously, sometimes at significant
expense. The faculty was concerned about the ability of the
administrative computing organization to implement a library automation
system useful to scholars. Equally important was their concern that the
automated catalog would be accessible only from a group of special
library devices. Those concerns were proven to be without foundation.
The Library Automation Project was completed on time, within budget, and
has been very favorably received, and the catalog is available from any
network-connected device. The automated catalog was accessed 18 million
times in 1989-90 and 46 million times in 1990-91.

Cost reduction, per se, was not a primary goal for these
organizational changes. In a very important way, though, our financial
efficiency was increased. Under the previous organizational structure
each organization would have had to add staff to build up the expertise
and depth that, during the merger, we built through reallocating about
20 percent of our positions. Indeed, staff reallocation has become a
routine part of our operations. Each year we "claim" about ten positions
as they become vacant and redistribute them across divisions in support
of new strategic priorities. Through retirement and sale of certain
assets of the previously competing network technology, we have recovered
funds sufficient to build a significant part of the new, common network
infrastructure. We are anticipating yet another increase in efficiency
through consolidation of the two physically separate data centers at a
single location.

What we would do differently

In retrospect, there are two important changes we would make to our
approach if we had it to do over. First, we would establish much earlier
a clear set of staff responsibilities for the new organization. Many
staff continued in their jobs from the previous organizations, and did
them very well. A few, however, became confused about their roles and
stopped doing anything for fear of doing something wrong. An
introspective paralysis crept into parts of the organization, but could
have been warded off through clear, direct communication among staff.
Were we to reorganize this extensively again, we would be far more
sensitive to leadership vacuums at all levels of management.

Second, we would much earlier establish a set of operating
procedures that fit the new organization. For approximately twelve
months following the merger, users met our failures at service delivery
with the lament "Oh, UCS is reorganizing." Clearly, this is undesirable.
A reorganization should result in better service, not worse. As it
happened, nearly every request for service was treated as new
organizational territory. Our users paid the price for our inattention
to operational routine.


NEXT STEPS

We began this article by describing the circumstances that precipitated
the merger of academic and administrative computing at Indiana. The
problems we faced involved not just academic and administrative
computing, though. They also centered on the changing relationships
among the UCS units, the University's media services organization, the
libraries, and the computing centers on other IU campuses, and on the
changing role of computing within the University. As an institution, we
are attempting to respond to these other issues as well.

Within Indiana University, the libraries and computing
organizations have traditionally operated as peers on projects of mutual
interest, such as various aspects of library automation. We did not want
to risk disrupting these positive working relationships, yet we needed
to bring a new focus to planning and coordinating the development of a
coherent electronic information environment. Our solution was the
creation of an Office of Information Resources, headed by an associate
vice president. The office carries out its functions of leadership,
coordination, and planning through two peer groups: The Information
Resources Council and the Information Resources Technical Advisory
Committee.

The Information Resources Council (IRC) is the locus of planning
and coordination functions. It is chaired by the associate vice
president, and has as members the dean of University libraries, the UCS
associate director for network systems, the executive director of radio-
television services, the director of computing for the Indianapolis
campus, the director of media services for the Indianapolis campus, the
UCS assistant director for data administration, and the University
director of facilities planning.

The theme of cooperation and partnership is underscored by each of
the members of the IRC taking University-wide responsibility for
communication and coordination in his or her functional area. All
decisions made by the IRC are to be based upon input from faculty and
administrative advisory groups and will be communicated widely through
existing University-wide organizations of head librarians, computing
center directors, etc.

The Information Resources Technical Advisory Committee (IRTAC) is a
group of the University's most accomplished technical experts, plus
technical representatives from our major technology vendors. It develops
technology standards and provides advice to the IRC and other University
agencies.

A major responsibility of the IRC and IRTAC in the next year or two
will be guiding Indiana's new Multicampus Technology Project.
Underwritten by a $22.5 million bonding authority from the state, this
project will use technology to establish stronger linkages among the
eight University campuses. Among its goals are the completion of all
campus data networks, the construction at all campuses of advanced
technology auditoriums and interactive video classroom-studios, and the
equipping of each classroom building with an adequate set of multimedia
instructional tools. These advances will enable the free flow of data,
voice, video, and graphics among all campuses, giving University
instructors unprecedented opportunities for intercampus collaboration.

One of our primary goals for the next five years is to use all
relevant technologies to increase academic productivity. We've seen the
significant effects of automation in improving administrative
effectiveness and efficiency in higher education; the task now before us
is to use the University's technology organizations as tools of
technology to boost IU's academic programs in unprecedented ways.

All of our analysis, planning, and restructuring efforts are aimed
at creating a technology environment in which the work of Indiana
University can flourish. As it has done in the past, the University will
continue to embrace new ways of gathering, processing, and using
information. Our challenge now, and in the future, is to provide
leadership in information technology within an adaptable management
framework. The metamorphosis we described above has involved difficult
changes in administrative structures and in relationships both human and
organizational. We believe strongly that those changes were necessary to
realizing the full potential of today's information technology and of
the institutions it supports.

************************************************************************