Association of College & Research Libraries
Managing automation for results: The role of the campus computing center
This is the second in a series of articles on practical management issues facing the planners and im- plementers of library information systems. The first article discussed using time productively (editing 500,000 OCLC records) while participative system selection (by library, data processing staff, faculty and students) proceeds; it appeared in C&RL News, November 1984, pp.532-39.
A central requirement for managing the planning and implementation of any automated library information system is obtaining quality data processing (DP) support. In the rush to figure out what systems best meet local needs and find financing, however, this vital aspect may be overlooked or at least underestimated. Yet the fact is that automated systems require DP expertise. The more library sites, integrated functions, records, queries, update transactions, staff involved and growth expected, the more expert that expertise must be.
The key questions, then, for planners and implemented are: What DP support does my library need, what optional sources do we have, and how can we manage it effectively? To ignore these issues, assuming that somehow they will work out, is to take unacceptable risks. All library types— college, university, school, special, government— must find DP expertise. This article discusses that need in general while focusing on academic libraries in particular.
DP services needed
Typically, libraries need many kinds of services from their computing center (CC) during the planning, implementing, and operational stages:
• Evaluation of hardware/software/telecom- munications offered by vendors of library systems. Having DP staff attend demonstrations and be part of site visits speeds up the library’s ability to winnow among vendor offerings.
• Preparing the written Request For Information (RFI) and later Request For Proposals (RFP). DP and library staff can work effectively in evolving documents that best meet library needs. Sections in each document on hardware/software/te- lecommunications are mandatory.
• Evaluating vendor proposals. As anyone who has been through that process knows, evaluating vendor proposals is at best a time-consuming, mind-expanding learning experience for the evaluation team. At worst, it is frustrating and time- wasting, e.g., flipping among several volumes of vendor documentation, never finding an answer that is allegedly there.
DP staff see questions that require followup telephone calls to the vendor’s DP experts; they are competent to evaluate information gained through those calls. Their analyses of the hardware/tele- communications configuration bid by the vendor will help prevent the unexpected and unwelcome hardware upgrades reported by Boss and McQueen.1 Those upgrades apparently were due to “lowballing” estimates of customer disk storage and CPU requirements in order to secure the contract.
Cr: UC Information Services
Library and data processing staff being trained for BLIS by Biblio-Techniques instructors.
• Getting specific operational information from libraries currently using the vendor’s system. I believe that no library should select a system without having key library staff take site visits to see the top two contenders’ systems in action. DP staff may join those visits, but also might be able to get information on the telephone from those libraries’ computing centers about operations and vendor support.
• Helpingselect the system. Both functional and DP specifications must be met in order to select the system. This means that both library and DP staff need to be on the team making the final selection, which will be forwarded as a recommendation to the parent organization.
• Providing expertise during contract negotiations and finalization. Every contract will contain a section on hardware/software/telecommunica- tions configuration requirements. Regardless of whether the campus CC, the vendor or a third party is providing equipment, the library must have this portion of the contract carefully reviewed by DP experts. Why? To assure that the configuration is more than adequate to handle file sizes, transaction loads and estimated growth.
• Helping set up implementation calendars. Implementation is the process that brings together several strands of tasks. They include site preparation for individual library sites (electrical, remodelling, cabling), computer room preparation, ordering hardware/software, designing cabling links and telephone line load balancing, designing acceptance tests, and scheduling the CC staff specialists needed during software installation. CC expertise is needed to identify the place of each task and strand in an overall implementation plan.
• Designing screens. Some systems, e.g., the Biblio-Techniques Library Information System (BLIS), permit extensive design of screens and screen sequences so as to meet different end-user needs. That’s useful when librarians feel that the needs and strategies of, for example, a two-year technical college student vary from those of a medical researcher. DP personnel must participate in screen design committees, which should also include faculty and student members, because their knowledge will help others understand the program processes going on behind those screens.
• Overseeing equipment installation and initialization in library sites. The CC staff who have worked with the library throughout the planning process have the knowledge to oversee the vendor, cabling personnel (which might be from the CC, physical plant, or a subcontractor), and library staff. The goal is the correct equipment located in the right place that communicates without error to the central processing unit (CPU).
• Operating the system. After being trained by the vendor, it is the task of CC staff to operate the library’s system. That means that the system is to be dependably up at agreed-upon hours, with proper security and backup being taken regularly. It also means that the CC helps the library solve problems.
In summary, DP support needed by libraries for automated information systems ranges from education, advice and review of documents to system operations.
Sources of DP support
There are five major sources of DP expertise available to most libraries: 1) parent organization computing center, 2) vendor of selected system, 3) outside service bureau, 4) consultant, and (5) library staff after proper training. Here we concentrate on the first case, but a few comments on the other options are in order.
The two major criteria for deciding where to go for DP expertise are 1) the degree to which the library wants to control its automated system; and 2) what it can afford. A related question is the degree to which it is ready and able to manage its DP expertise. One of the attractions of “turnkey” systems is that they take many responsibilities off the library’s shoulders. But as a leading vendor noted nonetheless, “A turnkey system implies that the library will operate the computer.”
In reality, the library will always have more responsibilities managing its DP expertise than it first expected. My experience suggests that the library has more leverage over its DP supplier the closer it is organizationally. In other words, a library that uses its parent organization’s computing center should be better able to get the dependable, quality service it needs than if it relies on the vendor; there are more levers with which to apply pressure.
However, if a library has no parent organization CC—and that’s different from not wanting to use it—then the library seriously contemplating automation must look outside. Service bureaus abound in the Yellow Pages. American Libraries classified ads list several consultants. If funds are very tight, then a dependable volunteer may be another source. Staff can be hired or trained to take on certain jobs, but there needs to be an expert source of DP knowledge to whom they can turn locally; for example, the University of Florida, which has set up a sizeable DP staff within the library, turns to both the North Eastern Regional Data Center, on whose computer the Northwestern University Technical Information System (NOTIS) runs, and Northwestern University, for assistance. Some vendors maintain the software remotely as well as prepare no-cost enhancements (Carlyle and Biblio- Techniques).
Merely having a parent organization CC doesn’t settle the issue. Many factors are taken into consideration, such as past library use, parent organization policies concerning CC availability to subunits such as the library, who pays for what, and the degree to which library plans have the support of the parent organization’s top management. Assuming that the CC is available, the real decision-making begins.
The library wants to be assured that the CC will give its production system—which must run dependably about 19 hours per day, 365 days per year—top priority. It has to have confidence that the computing center, as a fellow service unit, will treasure the library’s lifeblood. Why? Because the library cannot afford to have backup manual systems; it must go fully with the automated system and not look backwards. The issues are life and death for the library, yet it often fears that to the CC it is just another customer. Trust and confidence in the parent organization CC by the library is a primary issue.
Two campus service units
Developing trust and confidence between the library and the campus computing center may take some special effort. Differences in reporting structure, primary client group, and resource allocations may require frank discussions.
Often the CC and library report to two different vice presidential levels, with the CC under an ad- ministrative/finance VP and the library under the provost. As the keeper of a glamorous technology, the CC has often been much more successful in obtaining resources—budgets, personnel slots, space—than has the library.
Since most campus computing began in the 1970’s with the automation of administrative services, e.g., payroll and student registration, the CC often fell into an attitude that academic users, including libraries, were less important. Berry asserts that in those days, DP personnel would “tell the user that he not only did not know what he wanted, but was also incapable of understanding anything that would run on a computer.”2 3 The different ways that the two service units—CC and library—defined “service” often epitomized those differences, with the computer center concentrating on serving administrative user units and letting end-user academics find their own way. In contrast, the libraries’ primary user group are faculty and students.4 It is for these kinds of reasons that so many campus library information systems have been set up with little or no participation from their CC. While understandable, the waste is immense. Those DP staff have expertise that is directly relevant to the library in systems planning, implementing, and operations. If managed effectively, these two campus service units can collaborate to provide superior systems to end-users and to library staff.
That collaborative philosophy was the basis for the University of Cincinnati deciding several years ago that its Computing Center (UCCC) would assist the libraries in all phases of library automation, including facilities management. Two major advantages are establishing cost-effective hard- ware/software/telecommunication configurations and utilizing expertise. Both are contributing to the smooth installation of the Biblio-Techniques Library Information System in November 1985.
As of early 1985, a configuration combining stand-alone (for library use only) and shared (used campus wide) resources is in place. Shared resources used for BLIS include one-half of a 12-meg IBM 3033N mainframe located in the UCCC computer room, 3350 disk devices, a line printer and a COMTEN 3690 communications controller. Stand-alone equipment acquired by the libraries includes tape drives and rented ALA print train.
The combination of shared and stand-alone devices proved especially cost effective in providing access to BLIS by a maximum number of UC users. In addition to the 132 dedicated terminals in libraries, offices and departments can access BLIS through the campus telecommunications network controlled by the COMTEN. Sixteen dial-up ports also provide access from personal computers in homes and offices. These three methods will provide access to a far greater number of end-users than the libraries’ budget alone could support.
The second major advantage of working with the UCCC has been expertise. The Director, Library Systems Development, has been on loan to the libraries for four years. A senior systems engineer and senior programmer have been with the project for 2 years and are now experts in several mysteries, including OCLC records. Their work installing Northwestern University’s Technical Information System (NOTIS) has enabled staff to edit and de-dup over 600,000 OCLC bibliographic records in 14 months. Technical specialists and other UCCC staff have participated as needed. Using existing UCCC staff expertise saved the parent organization from hiring and supporting duplicative skills.
Facilities management agreement
I believe that the key to effective management of a campus CC by the library for the purpose of running a dependable, quality information system is having common shared expectations. When expectations about services, timeframes, problem detection, problem-solving and costs are shared mutually, then all parties have a common point of reference.
In those inevitable times of difficulty, e. g., when the system is down for repeated or extended periods of time, those shared expectations help resolve the division of labor needed to solve problems. They help reduce finger-pointing.
The University of Cincinnati libraries and computing center (UCCC) have written a facilities management agreement that sets forth shared expectations about operating BLIS. That agreement is augmented by a separate document concerning payments to UCCC for use of central site equipment and software.
The facilities management agreement was developed iteratively and jointly. The process began with a candid discussion of concerns on both sides under the guidance of the Dean and University Librarian and Vice Provost for Computing and Information Technology. The Systems Management Council, comprised of the heads of all five UC library jurisdictions, and key subordinates laid out their expectations. Drafts were reviewed by library and CC managers and by the Systems Management Council. The earlier and similar agreement drawn up by Johns Hopkins was very helpful.
Points of interest from the University of Cincinnati facilities management agreement for operating BLIS are:
I. Goals:
A. Provide faculty, students and staff online access to public catalog and circulation/reserve functions 7 days a week, 19 hours per day.
B. Based on experience, keep fine tuning the hardware/software configuration so as to meet service level objectives.
C. Set up problem-detection methods that spell out steps to be taken by the libraries and by UCCC, thus using everyone’s time most effectively.
II. Definitions, e.g., what library units are served.
III. Considerations about:
A. Central site, e.g., assure equipment security.
B. Relation to Biblio-Techniques, Inc., e.g., UCCC shall advise Biblio-Techniques of software failures that are beyond the scope of responsibility of UCCC. Furthermore, UCCC will coordinate software support for IBM products (OS/VS1 and related products). It is expressly understood that Biblio-Techniques assumes primary responsibility for the resolution of software-related problems for the application and the VM/VS1 portion of the system.
C. UCCC service level objectives, e.g.:
1. Operate BLIS from 7 a.m. to 2 a.m. seven days per week.
2. Maintain a telephone “hot line” during the above hours.
3. In the event of hardware or software failure, take all reasonable and expedient measures to correct the failure, notifying the libraries and Biblio- Techniques as quickly as possible.
4. Coordinate corrections of hardware failures with the appropriate service vendor, per existing service contracts.
5. Set up transaction logging.
6. Backup BLIS and the data base regularly, but not to exceed once every 24 hours.
7. Monitor response time of online transactions, on both a routine “snapshot” basis via a statistical report and for special diagnostic purposes.
8. Schedule printing of reports and other documents with the libraries.
9. Ensure the integrity of programs and data maintained by BLIS.
10. Configure the 3033N such that: at least 50 % of the 3033N is allocated for BLIS; and top priority is given to processing BLIS transactions.
11. With the libraries, plan for telecommunications growth to accommodate additional hardware and dial-up terminals.
D. Libraries’ responsibilities
1. Train staff in all units for all shifts to use mutually-developed problem detection/solving procedures.
2. Make every effort to solve problems locally, using mutually-developed procedures. Only when they are unable to proceed further in the procedures will libraries’ staff contact UCCC.
3. When reporting problems, staff will state how far they got in the procedures and report all data required by the procedures in order to assist UCCC in analyzing and solving the problem.
E. Management
1. Identify key UCCC and libraries persons responsible for BLIS performance.
2. UCCC and the libraries meet as frequently as needed but at least quarterly to review system performance.
Summary
Regardless of the source of DP expertise, successful collaboration between the library and that source is based on the library’s will to manage. Clear shared expectations about services, finances, and timeframes combined with maximum leverage should enhance the library’s ability to offer end-users dependable, high quality system services. A written facilities management agreement is one tool that helps set up shared expectations between two service units, the library and the computing center. When those two service units are part of the same parent organization, e.g., higher education, the library should consider management strategies and tools that will best assure system access and performance to support faculty, students and researchers. The academic library has a vested interest in managing its campus computing center effectively.
Notes
- Richard W. Boss and Judy McQueen, “Automated Circulation Control Systems,” Library Technology Beports 18 (March-April 1982): 171.
- Lyndon S. Holmes, “System Acquisitions and Vendor Expectations,” Library Hi Tech News 1 (June 1984): 112. Holmes is vice president of C L Systems, Inc.
- Dennis Berry, “Computer Services: Is This a Contradiction in Terms?” Cause/Effect 6 (Mav 1983):5.
- For a discussion of which organization, computing center or library, has the values to direct growing campus microcomputer use, see Alan E. Guskin, Carla J. Stoffle, and Barbara E. Baruth, “Library Future Shock: The Microcomputer Revolution and the New Role of the Library,” College & Research Libraries 45 (May 1984): 177-83.
Article Views (By Year/Month)
| 2026 |
| January: 7 |
| 2025 |
| January: 9 |
| February: 6 |
| March: 5 |
| April: 13 |
| May: 5 |
| June: 20 |
| July: 16 |
| August: 15 |
| September: 22 |
| October: 18 |
| November: 29 |
| December: 24 |
| 2024 |
| January: 2 |
| February: 0 |
| March: 3 |
| April: 15 |
| May: 5 |
| June: 5 |
| July: 4 |
| August: 3 |
| September: 3 |
| October: 7 |
| November: 7 |
| December: 11 |
| 2023 |
| January: 0 |
| February: 2 |
| March: 1 |
| April: 3 |
| May: 3 |
| June: 0 |
| July: 2 |
| August: 0 |
| September: 2 |
| October: 2 |
| November: 1 |
| December: 3 |
| 2022 |
| January: 0 |
| February: 0 |
| March: 0 |
| April: 0 |
| May: 10 |
| June: 3 |
| July: 2 |
| August: 2 |
| September: 1 |
| October: 1 |
| November: 1 |
| December: 1 |
| 2021 |
| January: 2 |
| February: 5 |
| March: 4 |
| April: 1 |
| May: 1 |
| June: 1 |
| July: 2 |
| August: 0 |
| September: 0 |
| October: 2 |
| November: 0 |
| December: 3 |
| 2020 |
| January: 1 |
| February: 3 |
| March: 2 |
| April: 5 |
| May: 3 |
| June: 4 |
| July: 3 |
| August: 1 |
| September: 2 |
| October: 1 |
| November: 2 |
| December: 3 |
| 2019 |
| January: 0 |
| February: 0 |
| March: 0 |
| April: 0 |
| May: 0 |
| June: 0 |
| July: 0 |
| August: 5 |
| September: 12 |
| October: 4 |
| November: 3 |
| December: 10 |