CAUSE/EFFECT

This article was published in CAUSE/EFFECT journal, Volume 21 Number 3 1998. The copyright is shared by EDUCAUSE and the author. See http://www.educause.edu/copyright for additional copyright information.

Changing (Almost) Everything and Keeping (Almost) Everyone Happy
by Craig A. Stewart, Douglas Grover, and R. David Vernon

Four years ago, the information technology organization at Indiana University/Bloomington undertook a major computing technology conversion that affected 40,000 people. This article describes the project and highlights the factors that contributed to its success.

In 1994 Indiana University/Bloomington possessed the largest cluster of DEC VMS systems in an academic setting in the U.S. The University�s VMS cluster was the primary computing environment for most of its 40,000 computer users, many of whom had never used a mainframe operating system other than VMS. The VMS cluster, widely viewed as user friendly, provided e-mail, a locally written information access system, and many third-party software applications. Problems with the VMS cluster, particularly problems in e-mail services, made it necessary to completely revamp the academic computing environment at IU.

A plan to replace the VMS cluster was announced late in the winter of 1995. Howls of protest erupted from loyal VMS users. Nonetheless, two and a half years later there were fewer than 100 VMS users at IU/Bloomington and the entire campus was making use of new academic computing systems. Furthermore, our computer user satisfaction survey showed that the vast majority of our customers were satisfied with the changes in our academic central systems.

Managing a change in computing infrastructure that affects 40,000 people was a substantial challenge. However, with change a constant in computing, periodic large-scale replacements of computing systems will be the rule rather than the exception for the foreseeable future. The strategies employed successfully at IU, which we describe in this article, should be applicable to other large-scale changes in computing technology and may be useful to others facing such challenges.

Background

Indiana University�s primary academic computing environment from the mid-80s to the mid-90s was based on VMS technology. During the summer of 1993 we added Alpha-based VMS systems to our VMS cluster. We suffered a number of �early-adopter� problems that resulted in severe system outages and dramatic difficulties in use of e-mail. IU�s technical experts were convinced that we could not meet the growing demand for academic computing services with further expansions of the VMS cluster. Instead, completely revamping IU�s central academic systems became an organizational priority.

Those involved initially in the project agreed upon the following guiding principles:

System architecture

The VMS cluster at IU had become a �one size fits all--poorly� system. E-mail often interfered with the performance of research applications, and vice versa. In evaluating new computing systems it was clear that RISC-based systems offered the best price/performance. Use of RISC-based systems meant adopting UNIX as the predominant operating system. However, UNIX was not widely viewed as user friendly. We recognized that the advantages of better price/performance for RISC systems would only be realized in practice if RISC-based systems were accepted, and thus used heavily, by the intended users of these systems. While drastic change was essential, we faced substantial obstacles in designing a new architecture that would be accepted by our user community.

IU�s academic computing environment in 1994 included, in addition to the VMS systems, three aging DEC Ultrix systems, a group of IBM RS/6000s dedicated to batch processing, and a pair of experimental UNIX systems--one devoted to e-mail and one devoted to Internet information clients. These systems dedicated to specific types of services had shown great promise because they could be configured and tuned optimally for the tasks performed on each system. We thus decided on a new system architecture based on multiple systems, each dedicated to a particular service. The services we targeted were e-mail, Internet information access, research computing, instructional computing, file serving, and general-purpose UNIX computing. The approach of a complete restructuring, including plans to phase out our Ultrix systems, did much to ease suspicions that someone in the computing center was �out to get� VMS.

A major problem in phasing out the VMS cluster was that it had been the point of integration for IU�s academic computing environment; it was where people received mail, where files were stored, and where applications were run. We established two new points of integration in the computing environment--the desktop and a common file store for central academic systems. When this project began, many of the desktop computers in use at IU were capable of supporting distributed computing applications (such as desktop Web browsing), but many were not. Because of this, we established multiple Telnet sessions to multiple hosts (each performing a specific function) as the least common denominator for desktop integration.

Figure 1 shows the changes over time in the capacity of general purpose central computing systems as compared to systems dedicated to specific services. To manage a smooth migration to the new architecture, we put in place the core of the new system architecture first, and then gradually decreased the capacity of the VMS cluster. This approach permitted the migration to proceed without anyone experiencing a substantial degradation in system performance, whether using the new systems or the old.

Figure 1: Changes in IU academic central systems during the central systems retooling process.
Figure 1

Marketing and customer communications

Even prior to our initial announcements it was obvious that the project to phase out the VMS systems would meet substantial resistance. Our communications began internally with our own computing center staff, then with our faculty advisory committee and departmental computing support staff, and finally with the general University population. The discussions with the faculty advisory committee provided good advice and endorsements of our plans. These endorsements helped to mitigate any perceptions that the computing center was issuing edicts to the faculty. Our focus on customer satisfaction was a key factor in gaining the endorsement of the faculty advisory committee and the support of the University�s computing staff.

Notification of the general computer user community began in February 1995 with an e-mail message to every VMS account holder. This message outlined the need for the conversion and the general timeline, and gave e-mail addresses and phone numbers for questions and help. We named the effort the �Central Systems Retooling Project� to emphasize the complete restructuring and improvement of the central academic computing systems rather than the elimination of VMS.

At the start of the migration project, we declared the VMS cluster to be a legacy system. No upgrades or enhancements other than those required for system security would be provided. After the end of the 1994-95 academic year new VMS accounts would be available only on a separate system dedicated to VMS applications used in instruction. E-mail was not offered on this system. This ensured that the user base of the VMS cluster and VMS e-mail would shrink over time as students graduated, while permitting faculty members some leeway in converting course materials from VMS to the new systems.

Since no single means of communication will reach all users we employed several simultaneous means of communication throughout the project. Information was sent to users in many ways, including e-mail, memos to all faculty, advertisements in the University newspaper, articles in the computing center newsletters, news segments on the University�s radio and TV stations, brown bag talks throughout the University, posters, and buttons for our staff. We also worked extensively with the University�s departmental computing support staff using IU�s leveraged support model.1 We received a very small number of complaints about our communications--a few from people who missed all of our communication efforts, and a few from people who complained of being bombarded with information.

Migration of information access

In analyzing usage patterns of IU�s VMS systems, we know that the most widely used applications were e-mail and information access through the Academic Information Environment (AIE). The AIE was a text-only, menu- driven system for sharing information within the IU community. Information and services available through the AIE included the campus calendar of events, answers to commonly asked questions about computing, and library services such as requests for interlibrary loans. Only a small percentage of the VMS users used applications other than e-mail and the AIE.

As of early 1995 relatively little within the AIE was considered mission critical. It was thus a good first step in the migration from VMS to other computing systems, because it would involve many computer users but not activities that were highly critical to the operation of the University. The World Wide Web was still new to most users, but it was sufficiently well established that it was a realistic choice for the University�s information exchange. Migration from the AIE to the Web was announced in February 1995, to be completed by the end of June. The publicity campaign for this phase of the project was based on the theme, �Catch the world in your Web,� which caught people�s attention and added an upbeat tone to the initiative.

The migration from the AIE to the Web involved tens of thousands of computer users, so enabling them to learn about and use the Web was a critical challenge. We produced extensive documentation about using the Web and offered classes about switching from the AIE to the Web. We also made it easy for people who had suitable desktop systems to install Web browsers configured for IU�s computing environment, and thus provided these people access to the most current graphical Web browsers. For students dialing in to IU�s computer systems, or people on campus whose desktop computer could not support a graphical Web browser, we upgraded the central system dedicated to Lynx and other Internet information clients.

A key tactic employed in the AIE-to-Web migration, and then throughout the rest of the project, was to make changes self-documenting whenever possible. Thirty days before we removed the information in any portion of the AIE, we posted the information within it on the Web. A notice was added to the affected section of AIE announcing its impending migration. Once information was removed from the AIE, we put a notice in its place providing its new Web location and information on how to get help adapting to the changes. This assured that people using the AIE received good information about the changes even if they missed our notification efforts completely. The AIE was gradually and successfully reduced to a shell containing nothing other than pointers to the new Web locations for information sources by the end of June 1995.

The concerted effort to move from the AIE to the Web put IU in a leading position among universities in using the Web as a means of institutional information exchange. Comments from our advisory committee and informal feedback from IU�s computer users indicated that the project had been successful in improving IU�s ability to access information through computers.

Applications software

After the migration from the VMS-based AIE to the Web in the first half of 1995, we turned our attention to applications software from DEC and third-party vendors. In migrating applications software we deviated from the traditional wisdom of systems management intentionally and successfully. Traditional wisdom is that changes should be made at times when system usage is low (which at universities is when classes are not in session), tested by the computing center, and ready for use when students and faculty return to campus. The critical flaws in this approach are that the computing center is generally not able to adequately test changes, and the times when people are returning to campus (typically at the beginning of a semester) are the times when they are least able to tolerate problems with computing services. We thus took a different approach.

When we migrated applications software from the VMS systems to new UNIX systems, we made changes in small increments, while classes were in session and typically during the middle of the week. If a change caused a problem that had not been revealed by our testing, we found out about it immediately and were able to either fix it quickly or back it out. By ensuring that changes were frequent but small, the computing center was able to react quickly to any individual problem and provide good support for the people affected. Because changes were very fine-grained, each user was directly impacted by changes only once in a while. Because we provided deadlines for availability of specific applications, rather than dates on which people would lose their accounts, people could decide for themselves when to make the switch to a different system as their primary computing platform. Removing systems from the VMS cluster provided a gradual decrease in the capacity of the VMS cluster (as usage decreased) and greater capacity in UNIX environments (as two VMS systems were converted to Digital UNIX). The periodic removal of a system from the VMS cluster also helped remind people that the project was progressing steadily and could not be ignored.

Altogether we migrated more than fifty applications software packages from the VMS cluster to other platforms. IU�s computer users knew and liked VMS and were sure that they would dislike UNIX. Our communications with users emphasized the view that they would benefit from the switch to RISC-based UNIX systems because their applications software would run more quickly as a result. We also emphasized that knowledge about any application is largely transferable from one operating system version to another, and that most computer users know far more about the applications they use than the underlying operating system. This view led us to create a document targeted specifically at the UNIX-wary. This document was entitled �UNIX: The least you need to know,� and included just that--the least a person could know about UNIX and successfully run applications in a UNIX environment. Also included in this document were sample scripts for batch jobs (electronic copies of which were easily accessible online) and a VMS-to-UNIX command translation table. Pico, with its on-screen menu, was made the default editor on all UNIX systems to ease the pains of changing editors.

As with the migration of the AIE, changes in applications software were made self-documenting. For example, when a person typed the command for an application that had been removed from the VMS cluster, s/he was presented with information about changes in the software�s availability rather than a cryptic error message.

Most users migrated from one time-shared system to another. However, some people possessed desktop systems of sufficient power that a switch to microcomputer versions of software packages was a good option, particularly because this change was usually accompanied by an improvement in the user interface. Site licenses for commonly used software were especially effective in encouraging people to migrate from shared systems to their own desktops. For VMS-based applications with small numbers of users, it was sometimes better and less expensive for the computing center to purchase a microcomputer version of the application for each user than to move the application to a different central server.

One surprise in the migration of applications was the relatively light demand for consulting help. During the course of the overall project we produced more than one hundred written documents (made available both online and in print). We believe that the production of good documentation at the beginning of the project greatly eased the demand for consulting.

As part of the transformation from an environment of general-purpose academic systems to an array of hosts, each specialized for a particular purpose, we also phased out our general-purpose Ultrix systems. These migrations came primarily during 1996, after the bulk of VMS applications had been moved. The staging of application removal from Ultrix platforms again made the transition straightforward to manage. The migration from one UNIX environment to another presented little difficulty for most users. There was a relatively small group of users, mostly people interested in computer science, who claimed a need for a general-purpose UNIX environment within which a person could, for example, simultaneously access newsgroups, send mail, and run Perl scripts. For these people we provided a small but fast general-purpose UNIX server so that they could work in a fully functional, general-purpose UNIX environment.

E-mail migration

E-mail was by far the most critical part of the conversion. Our first step in e-mail migration was to encourage voluntary migration from VMS mail to Pine during the early spring of 1995. Pine was delivered at that time from a Hewlett-Packard SMP system. A utility program was written that made it simple for people to migrate their stored mail, maintaining folder structures, from VMS mail to Pine.

After some early successes, we began to experience some performance problems. Hewlett-Packard was very considerate in loaning us a larger SMP system to get through the year, and we asked people to stop migrating from VMS mail to Pine until after the end of the 1994-95 school year. We decided to switch to a horizontal scalability approach using multiple smaller HP systems, with each user assigned to one system. Because the name of the original system had been tainted by its performance problems and to spark interest in the new systems, we held a contest to name the new systems. The winning entry, submitted by a student, was a suggestion to name the systems after characters in Shakespearean plays. The contest created a sense of participation on the part of the students and helped maintain an upbeat tone.

Worries about the impact of even a short period of disruption of e-mail services caused us to make the change from a single SMP server to multiple single-processor systems during the summer. We felt that with systems that were relatively simple--delivering only e-mail--we could adequately test the changes. Thanks to good use of name serving, all mail sent to or within IU/Bloomington was simply addressed to [email protected], making it easy for users to adjust to the changes in host names.

When students returned to campus in the fall of 1995 we discovered that the new e-mail architecture delivered excellent performance, and informal reaction to the new systems was highly favorable. We resumed plans during academic year 1995-96 to phase out the use of VMS mail. We adopted a strategy similar to the IRS approach to tax-filing deadlines. By default, every user (except seniors) would lose access to VMS mail on March 15, 1996. If a person requested an extension of access to VMS mail an extension until June 30 was granted automatically. Requests for access beyond June 30 required an explanation of the continuing need. Early adopters migrated from VMS mail in the fall. The sense of imminent change created by the March 15 deadline encouraged a wave of migration early in the spring semester. The people who delayed changing and requested extensions beyond March 15 at least understood that they needed to switch from VMS mail to Pine in short order. We received fewer than 500 requests for access to VMS mail after June 30, 1996.

Once the migration from VMS mail was completed, the remainder of the project was largely anticlimactic. The Ultrix systems were phased out with the same strategies and tactics we had used with the VMS migration. Usage of VMS dropped drastically, and only people who had complicated migration problems were left using the system. At the beginning of the next academic year we announced that unless people asked for an extension, accounts on the VMS system would be terminated as of June 30, 1997. There are now only a handful of people using our lone, small VMS system, and we plan to eliminate VMS completely by July 1, 1999.

Things we learned

Overly ambitious initial project goals increase the difficulty of gaining user acceptance.
Early discussions about the project within the computing center involved unrealistically short timeframes for the project. These discussions became known through the rumor mill, generating negative feelings prior to our initial public announcements about the project and increasing the challenge of gaining user acceptance. Thus negative (and generally incorrect) information was travelling around campus before we were ready to make announcements about our plans. We reacted to this situation by speeding up announcements and going on an intensive information campaign. Still, the negative feelings caused by rumors resulted in greater initial upset on the part of our users initially than was necessary and caused us to devote more time in face-to-face communications with worried users than would otherwise have been necessary.

Notification far in advance of changes helps customers adapt to the idea of change.
We provided extremely long notification periods for system and service removal primarily because we feared that users would have very long and complicated migration tasks. The primary benefit, however, was that our customers got over their initial emotional reaction to change prior to the actual initiation of migration work.

Student turnover can be of great help in migration projects.
We timed the large-scale aspects of our migrations so that in any given year, most seniors could ignore the changes. Retraining experienced users is often harder than initial training of new users, so this strategy greatly enhanced customer satisfaction and eased the support burden faced by the computer center.

It�s all right to be a little corny.
We did a number of things that were a bit corny, such as the �Catch the world in your Web� theme for the AIE-to-Web migration, a �movin� on up� theme for the VMS-to-Pine migration, and the contest to name the new mail systems. This was helpful in that it encouraged public awareness and injected a bit of fun into the process.

Proactive documentation provides greater value than reactive consulting.
At the beginning of the project we responded to many requests for documentation and demands for extensive consulting. By providing extensive documentation (paper and online, including good access to online manuals) we often gave users the tools they needed to solve their own problems with little or no consulting help from the computing center. People benefited greatly from knowing that consulting was available, but many needed little or no consulting help.

Change is a constant.
One of the most frequent questions we received during this project was, �If I make this change now, can you promise me I�ll never have to go through this again?� We always answered this question with �Absolutely not!� In that sense, this migration provided extremely valuable long-term user education by setting an expectation of continual change in computing systems.

Conclusions: the user response

We achieved our project goal of 95 percent customer satisfaction. IU�s University Information Technology Services conducts a formal customer satisfaction survey each spring in which surveys are sent to a random sample of IU�s faculty, staff, and students.2 The spring 1996 survey included the following question: �During 1995-96 the computing center has made a major effort to improve our shared computing systems. This Central Systems Retooling Project included as its goals migration from the Academic Information Environment (AIE) to the World Wide Web (WWW) and migration from VMS Mail to Pine. Please rate your overall satisfaction with this project.�

On a standard Likert (1-5) scale, with 5 being �very satisfied� and 1 being �very dissatisfied,� the average score was 3.99 (�0.11), with 94.4 percent (�3 percent) of the respondents providing a response of 3 or higher.

The spring 1997 survey, conducted after the migration from VMS had been essentially completed, included another question about satisfaction with the migration project. The average score was 4.00 (�0.07), with 95.8 percent (�2 percent) of those surveyed responding with a 3.00 or higher.

This project, while very demanding of both the computing center and our customers, was extremely successful. IU has a better computing environment today as a result. The project was widely criticized when first announced; in the end, however, the vast majority of the people affected by the change were satisfied with the benefits they accrued as individuals as a result of changes in the computing environment. People were also satisfied with the way in which the changes were implemented. We could have done the same project more quickly, but at the expense of customer satisfaction. By working carefully with our customers to ensure that their concerns and needs were addressed throughout this project, we were able to achieve simultaneously technical excellence and tremendous customer satisfaction.

Acknowledgements

This project would not have been successful without the leadership, advice, and support of many people in Indiana University�s UITS organization, too numerous to name, and the good will and patience of the IU user community. Special thanks go to the members of our faculty advisory committee and the members of the project team.

Sidebars

Buy-In Begins at Home

Many computer center staff were deeply invested in the technologies we were planning to phase out. How did we gain their acceptance of the plan?

Project Chronology

Keys to Success

Endnotes

1 B. Voss, Leveraged Support Model, CNI Institution-wide Information Strategies (IWIS) Indiana University Case Study, online at http://www.cni.org/projects/iwis/97rep/iwis97.indiana.html.

Back to the text

2 Details regarding the UITS user satisfaction survey are available via the Web at http://www.indiana.edu/~uitssur/survey/index.html.

Back to the text

The authors are staff of University Information Technology Services at Indiana University. Craig A. Stewart ([email protected]) is acting director, Research and Academic Computing; Douglas Grover ([email protected]) is operations and instructional support supervisor; and R. David Vernon ([email protected]) is senior technical advisor.

...to the table of contents

Menubar Imagemap