Copyright 1997 CAUSE. From CAUSE/EFFECT Volume 20, Number 1, Spring 1997, pp. 57-59. 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 Julia Rudy at CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301 USA; 303-939-0308; e-mail: [email protected]
The University of California, Berkeley's Information Systems and Technology division developed a service approach to meeting the challenge of providing off-campus Internet access to more users at a reasonable cost, from wherever they access the campus network, while maintaining quality control over services and support. For this service-oriented approach, the University received the 1996 CAUSE Award for Best Practices in Service.
The Information Systems and Technology (IST) division of the University of California, Berkeley has for many years provided free, off-campus dial-up access via modems to campus computers, a service traditionally used by information systems staff and a few faculty members. But with the widespread growth of the Internet, e-mail, and the World Wide Web in recent years, a very large portion of the campus community found access to the network to be essential to their teaching, learning, and research activities. Since much of this activity takes place off-campus, in dorm rooms, homes, or even from across the country, IST began to experience enormous pressure to expand and improve off-campus network access. In 1994, SLIP/PPP1 service was offered and more high-speed modems were added to the 600-modem pool to try to keep up with the accelerating demand among the University's user base of 44,000 students, faculty, and staff.
The BIK allowed users to install everything needed for networked computing in one sitting. The package contained appropriate IP components, an e-mail client (Eudora), Netscape, news readers, etc., in a suite known to run in a standard set of environments (Mac OS 7.x, Windows NT, Windows95, etc.). An installation mechanism allowed the user to configure the individual pieces by following the instructions included with the kit. This reduced user questions because the "kit" installed everything needed.
The BIK was released in the fall of 1995. We developed a "one-stop shopping" Web site that enabled new users to set up an e-mail account and a home-IP account online. Users without access to networked computers were invited to use those in our open-access computer labs. The Web page also permitted them to automatically download the BIK to diskettes, an option which proved to be problematic. Downloading took too much time and was prone to failures, increasing the workload of the computer labs. Failure to read the documentation increased the number of contacts with our help desk.
In the spring semester of 1996, we produced the BIK in a "shrink-wrap" package that contained printed documentation and all of the software on diskettes, priced to cover only production costs. We then actively discouraged downloading in the labs. This "BIK-in-a-box" proved to be very popular -- 2,500 boxes were sold during the spring semester.
During BIK development, IST began discussions with ISPs who had shown an interest in marketing their services to the campus. NETCOM met our basic requirements for an ISP fee (PPP services, P.01 grade of service,2 and nationwide points of presence). Furthermore, they recognized that our BIK contained a far richer suite of functionality than the all-in-one package they provided. Since we were already providing e-mail to our users, it would not be necessary for them to do so. We were able to quickly develop the NETCOM Higher Education Access Program, whereby they would provide dial-tone service to any campus customers at reduced rates, while IST provided e-mail services and the BIK software.
NETCOM provided twenty-four-hour, seven-days-a-week toll-free telephone support, much more extensive coverage than IST's help desk could offer. It made sense for NETCOM personnel to provide the first level of support, since the majority of calls would involve problems with network transport and account administration, about which we could do nothing. We provided them with current releases of our software and documentation, including ongoing software updates and revisions. Furthermore, we trained their support staff in the installation, configuration, and use of our software on both Macintosh and Windows computers. They agreed to make every effort to resolve campus customer problems and to refer problems they could not resolve to our support staff via e-mail.
NETCOM began advertising their new customized services to the campus in December of 1995. We felt that we had developed an adaptable model under which we could outsource dial-tone access to the campus network, and at the same time ensure a very high quality of service tailored to the unique needs of our users at more affordable rates.
Our ISP partnership was also well received, and its success attracted other ISPs to working with us. IST concluded a pilot study with Metricom -- a provider of wireless data communications -- and later releases of the Berkeley Internet Kit were pre-configured for use with a Ricochet modem. The Ricochet University Partners Program is largely a clone of our NETCOM agreement.
After two years, however, we have a broader perspective of the issues involved in providing low-cost, reliable Internet access to a large campus population. Several unintended consequences have led us to rethink our approach, and we would now not recommend the course of action we took to another institution.
Alas, there was a considerable resistance on the part of the campus community to paying for a NETCOM account -- despite its competitive pricing and reliable connectivity, and even though it is more difficult than ever to obtain a dial tone from our modem pool. While we continue promoting the benefits of the service to those who can afford it, we cannot yet discontinue our free modem pool and do not expect to see any reduction in the load on those modems for a long time.
Besides not realizing any relief from modem-pool support, the success of the BIK had an unexpected effect on related services. The number of new requests for free electronic mail skyrocketed in conjunction with the introduction of the BIK, no doubt due to the coupling of the BIK with this service on the "one-stop-shopping" Web page. The BIK's success also created a tremendous number of requests for assistance at our help desk; staff are now overwhelmed by the volume of BIK support required. While we continue to engineer the BIK to be ever more fool-proof, the intrinsic complexity of dial-up Internet software continues to be problematic for our users, who are mostly not computer literate.
Also, the more we improve the BIK for the users, the more complex and prone to error it becomes. We are at the mercy of the vendors of BIK components (Netscape, Qualcomm, etc.), and often find ourselves pushed against deadlines, waiting for the latest release of some component of the BIK. The increasing complexity of operating systems and the rapid change in them also keeps us scurrying to keep up.
We have come to the conclusion that the very idea of supporting users remotely, that is, via telephone or in any manner by which we do not have direct access to the computer in question, is ineffective. The networking and operating system components are so intertwined and dependent upon one another that in many cases we need to personally examine the computer itself to determine the cause of failure. We are now exploring alternate support models to address this need.
There are also ISP-related support problems. Supporting a multitude of different value-added packages represents an enormous cost overhead for an ISP compared to supporting only one such package. Our NETCOM collaboration led them to improve their value-added software package (called NETCOMplete) which they now promote instead of ours in an effort to reduce their end-user support costs. In addition, our arrangement with NETCOM (whereby we provide e-mail and they provide the end-user support) works poorly for them. The costs of providing e-mail to a large number of users is trivial compared to the cost of supporting those users. Their NETCOMplete package includes an e-mail account and is easier for them to support.
We are working with ISP providers to develop ways to leverage their services to make them attractive for reasons other than ease of connectivity (for example, by providing Web space, something we do not offer). Also, we are encouraging them to increase their marketing activities, albeit with little success so far. We are also exploring the possibility of "volume purchase" arrangements, by which we might buy a large number of accounts in a block for re-distribution to campus users at a (possibly) subsidized and, for the end-user, reduced cost.
In the first case, the major manufacturers of operating systems are racing to integrate dial-up networking capability into their systems. The need for custom installers to correctly install and configure complex Internet/PPP connectivity software will become unnecessary.
With regard to applications, the actual functionality of most network software will become available as components integrated with the desktop. The need for stand-alone applications to perform particular network tasks will become superfluous.
Of course, fully integrated dial-up networking and comprehensive component architectures are still works in progress. So we expect that the BIK will continue to enable users to get started on the Internet until the convenience it provides is commonplace in vendor-supported systems. In the meantime it will evolve to take advantage of new technologies and provide a bridge to them for our users.
Major contributors to the BIK project, in alphabetical order, were Alexis Dinno, Computer Resource Specialist II; Karl Grose, Programmer/Analyst III; Sarah Jones, Programmer/Analyst I; Jeffrey McCullough, Programmer/Analyst IV; Seth Novogrodsky, Programmer/Analyst II; Aron Roberts, Programmer/Analyst III; Rob Robertson, Programmer/Analyst III; Anthony Roybal, Programmer/Analyst II; Shuli Roth, Programmer/Analyst III; and Austin Shelton, Programmer/Analyst IV.
Other contributors were Valerie Adams, Senior Electronics Technician; Jerry Berkman, Programmer/Analyst III; Robert Callaway, Senior Analyst; Jacqueline Craig, Computer Resource Manager I; Nory Ison, Programmer/Analyst IV; Katy Katz, Senior Analyst; Roger Rosenblum, Programmer/Analyst III; Greg Small, Programmer/Analyst III; Tamara Sturak, Programmer/Analyst III; and Jane Wolff, Programmer/Analyst III.
This article was adapted from a UC Berkeley Web page (see http://wss-www.berkeley.edu/cause/index.html).
2P.01 means that the customer will not receive more than one busy signal for every 100 calls to the ISP's modem.
Austin Shelton ([email protected]) is a Senior Technical Consultant and currently supervisor of the Macintosh Technical Support Team at the University of California, Berkeley. He has been a systems programmer and analyst since 1978, and has worked with client/server technology since the mid-'80s, when he helped develop the POP3 server system now in widespread use around the world.