Library Acquisitions: Practice and Theory, Vol. 7, pp. 189- 194, 1983

Printed in the USA. All rights reserved.

0364-6408183 $3.00 + .OO

Copyright Q 1983 Pergamon Press Ltd

ALA ANNUAL CONFERENCE, 1983

DEVELOPING AN AUTOMATED ACQUISITIONS PACKAGE

SANDRA WEAVER

Innovative Interfaces, Inc.

2131 University Avenue #334

Berkeley, CA 94704

INTRODUCTION

Few libraries today have the opportunity to design or build their own acquisition system from scratch. But if you were to design such a system, what would be your design criteria? Wouldn’t you want it to perform all your present manual acquisition tasks? Would you expect it to do even more-such as analyze the data and provide useful reports whether about

bibliographic items, funds, or vendors? Shouldn’t your system talk to all your other systems? Would you want it to be able to grow both in size and in functions as new needs arose? And of course, wouldn’t you demand that it be fast and easy to use?

The INNOVACQ Library Acquisition System was developed from scratch specifically to handle library acquisition tasks, and it was developed with just such desires in mind. When Steve Silberstein and Jerry Kline founded Innovative Interfaces, previous experience had already provided them with the ideas for an on-line acquisition system. The opportunity was there to build their ideal system, and build it they did.

So let’s look at the components of that ideal system and how it evolved into the INNOVACQ.

DESIGN PRINCIPLES AND GOALS

Before any work was actually started on a system, the goals of the system were established. Basically, there were five overall goals.

Ms. Weaver’s presentation was originally delivered to the ALA RTSD Automated Acquisitions/In-Process Control

Systems Discussion Group on June 27, 1983.

189

190 SANDRA WEAVER

Goal Number I: All Manual Acquisition Functions Must be Met in the On-Line $\stern

To be considered at all successful, the system would have to perform all the functions of a manual system. Among the functions to be included were ordering, receiving, claiming, payments, fund accounting, management reports, and retrieval by various access points.

Goal Number 2: The On-Line System Should Provide More Service to the Librar.1, Than the Manual System

Functions that were tedious under the manual system should be done by the on-line system. For instance, the system should automatically find all records that require that claims be written.

Besides just storing and retrieving data, the system should be able to analyze that data and present it as meaningful information. For example, funds should be able to be grouped in hierarchies with the system supplying subtotals and totals. Vendors should be analyzed for performance. New acquisition lists should be generated easily and sorted in whatever order the library wants. Up-to-the-minute reports on which funds are over- or underspent should be available. Displays of information should take various forms and be available both on-line and in hardcopy form. These were just a few of the demands that would be placed on the new system.

Goal Number 3: The System Must be Eas_y to Use Ease of use encompassed a multitude of actual meanings for this system. First, the system

would have to be easy to learn-an extensive command language requiring a lengthy learning span was considered undesirable. The system would have to be user-friendly by presenting all available options at any point in time. The system would have to be efficient-all data should only have to be keyed once. Automatic copying of data should be available from record to record, or from another system. And, of course, the system should be fast.

Goal Number 4: The System Must be FL& Integrated

The system would have to be integrated in two ways: externally and internally. Externally. the system would be required to interface with all other automated systems in use by the library. These would include cataloging utilities, circulation systems, on-line catalogs, and vendors, as well as accounting systems used by the parent agency of the library.

A further demand was placed on the integration between systems. Any process that could be initiated from one terminal should have that process transferred throughout the entire linked system by a simple command. For instance, if you are sitting at your cataloging terminal and find a record for a book that you want to order, by inputting a simple command at the cataloging terminal the record should be transferred to the acquisition system, an order generated, the fund encumbered, and an on-order record transferred to your circulation system. This one-stop processing with no repetition of keying was seen as a must.

Internally, all the files in the system were required to be integrated. The bibliographic files would have to be interactive with the fiscal files, both of which would have to be interactive with the vendor files.

Goal Number 5: The System Must be Flexible The system would have to provide flexibility within the record structure, not only to

accommodate changes within a single library, but also to support the variations between

Developing an Automated Acquisitions Package 191

different libraries. For instance, bibliographic records would have to consist of a variable number of fields; these fields would have to be variable in length, and all fields would have to be repeatable and indexable.

The system would also need to allow for expansion and addition of memory, terminals, and functions.

DEVELOPMENT PRIORITIES

Normally, the number-one priority in developing any system would be. the attainment of a thorough knowledge of the routines and functions that the system should encompass. Both Steve Silberstein and Jerry Kline were instrumental in developing and implementing a batch acquisition system at the University of California at Berkeley in the mid-1970s. Having spent some years both in development of the Berkeley system and listening to the day-to-day feedback from staff, the basic research and knowledge into acquisition needs had already been done by these two. They also had some ideas of their own about how computer systems should work and these ideas helped shape the development priorities.

First Priority: The Right Hardware There existed numerous criteria by which the hardware for this new system would be

judged. The computer would have to be reliable, powerful, and expandable. Additionally, the computer would be required to have second-source availability; in other words, it would have to be available from more than one manufacturer. The components of the system would need to be able to talk to each other with computer-industry standard interfaces. Lastly. the computer would have to be simple to install, without the necessity of expensive remodeling or air-conditioning.

To achieve reliability, a microcomputer system was the choice. In the computer industry, each phase of development has produced more reliable hardware. We have progressed from vacuum tubes to transistors and now to chips, just as we have progressed from mainframes to minis to microcomputers. .With denser storage, fewer discrete components, and fewer mechanical contacts, the newer microcomputer chips are more reliable than older methods.

To achieve greater reliability, the choice for data storage was a Winchester disk drive. The Winchester is a hard disk that is totally enclosed and much less susceptible to environmental hazards such as dust, smoke, or hair.

To achieve power, a multiple processor machine was the one of choice. With a multiple processor system, the entire system can be efficient, fast, and can contain large amounts of main memory. For instance, the system we have installed at the University of Michigan has 3/4 of a megabyte of main memory. This is approximately four times the main memory found in the average minicomputer system in use today.

The multiple processor system also added to the reliability of the entire system. If one central processing unit should fail, the other processors would continue to function. Multiple CPUs also prevent degradation of response time as more terminals are added to the system. In the INNOVACQ system, one central processing unit drives two terminals. As more terminals are added to the system, more CPUs are also added, providing more power and continuation of high response time.

The multiple processor system also allows for expandability. As more power or more terminals are required, another CPU can be plugged into the system. The net result is that the

192 SANDRA WEAVER

architecture of this system does not require any trade-offs or compromises between power, reliability, and expandability.

Criteria for system terminals also existed. The terminals were required to be non-modified, industry-standard terminals and had to be widely available. In other words, one should be able to walk into almost any computer shop in the country, buy a terminal, and put it onto the system. Backlogs in production or customization would not be tolerable. The other criterion for the terminal was that it be capable of high-speed transmission-9600 Baud or higher. The system would be run at a high speed, and the terminals would need to accommodate that speed.

Demands were also made on the programming language that was to be used in the system. Here we verge somewhat into software considerations. Rather than software programs, 1 am talking about the type of language that the hardware would support. A high-level, fully structured language that was also widely supported in the computer industry was desirable. A fully structured language was required so that programs could be more easily modified and maintained. An industry-supported language was required so that the same language could be operated on hardware from different manufacturers and programmers would be easier to find. The resulting language used on the INNOVACQ system is PASCAL.

The storage structure for data is vitally important in terms of retrievability and manipula- tion. Packaged database management systems are one means to acquire this structure, and several were on the market. Unfortunately, finding one that could handle the complexity of bibliographic records was difficult, and was not available for our chosen multi-processor system. Since an adequate database management system could not be found, the decision was made to design and program one tailored to the needs of the 1NNOVACQ system.

The resulting hardware configuration for the INNOVACQ consists of a microcomputer system incorporating multiple central processing units and a Winchester hard disk drive. The computer itself is small enough to sit on a regular desk surface and requires no special air conditioning. Depending on the number of records to be stored in an individual system, the disk drive may be incorporated into the same physical box as the computer or may be contained in a separate box of the same dimensions, which can be stacked beneath the computer. Each library’s INNOVACQ is a separate stand-alone system containing the data for that library.

The standard start-up configuration includes two terminals, although up to 14 terminals may be used on the system. Also included in the standard hardware configuration is a hardcopy printer for printing of reports, purchase orders, claim letters, etc. A video recorder is provided to back up the database for security purposes. A modem is also supplied so that our staff may access a particular library’s system for diagnosis and program modification.

Software Priorities All software to be used on the system was to be developed in-house. One of the demands

put on software design was that all programs be table-driven. In other words, no code values, names of fields, etc. should be contained in the actual program but rather in a table, which could be used by the program. This design allows each library to build its own tables of code values, etc. It also protects the reliability of the programs.

Obviously, not all of the acquisition functions could be designed and implemented simultaneously and priorities had to be established for these. The highest priority of software development was in the fiscal routines. Due to the sensitivity of fiscal records and the need for total accuracy, it was decided that the fiscal routines must be fully operational before a library

Developing an Automated Acquisitions Package 193

even began building its bibliographic database. To add fund data to records once they were in the system would be difficult, especially if adequate audit trails were to be kept.

Other early priorities in software included the means for inputting and updating records, retrieval of records by a variety of methods, production of purchase orders and claims, and vendor files for maintaining addresses and statistics. These were only the very basic priorities for the early development. However, this is not to say that all of the “fun” ideas had to wait until the end. Some ideas, such as the graphing of fiscal information, were included in the system in the very early stages. By the time the first INNOVACQ was installed, the system provided routines far beyond the initial priorities.

The INNOVACQ, as initially offered, was developed to meet the specifications of two academic libraries. These two libraries, the University of California at Riverside and California State University at Long Beach, not only provided specifications but served as test sites for the first installations. The staff were active participants on design considerations and suggestions.

The determination of priorities for continuing development has often been in response to a new user’s needs. For example, two developments done for two Canadian libraries, the University of Montreal and Ontario Hydro in particular, come to mind. First, although the

system provided conversions of foreign currencies to a standard base, the needs of the Canadian libraries to perform currency conversions for approximately 85% of all their records called for modifications in the way the conversion program worked. Secondly, the instructions and screen displays had to be provided in French.

Priorities for ongoing developments include new system functions, such as Serials Check-ln. which was recently introduced at the University of California Boalt School of Law. Still other priorities include system improvements and needs that we have encountered since the first installation. For example, in the first fiscal routines, funds could be arranged for management reports in a hierarchical structure with four levels. It soon became apparent that even four levels were too restrictive and rigid. As a result, the programs have been modified to allow much greater flexibility. A library may now design several of their own management reports. In each report, the funds may be arranged in any configuration and include hierarchical levels into the thousands. Each report may contain all the funds of the library or just a subset of the funds. The result for the library is the capability of producing reports that meet many needs.

The INNOVACQ, as available today, provides for all the basic acquisition functions as well as many extra features. Just a few of the highlights of these features are: l Searching that is fast, easy and that will always provide a result l Boolean searching on all codes. Resulting records may be sorted by any two fields, and the

printed list may contain as few or as many of the data elements as desired l Interfaces from the OCLC, RLIN, or UTLAS cataloging utilities l Interface to CLSI l Serials Check-In l Statistics with cross tabulations by selected fields l On-line and printed graphs l Two-Step Total Process: one step to find bibliographic information, place order, and en-

cumber fund; one step to receive material, disencumber and expend on fund. One of the features extremely important to a library is that for each installation, the library

determines its own values for codes, its own names and codes for variable length fields, and which of those fields are indexed. Parameters also tell the system whether to supply English or French screen instructions, which cataloging interface program to use and even which communication program will be used by CLSI.

194 SANDRA WEAVER

IMPLEMENTATION

The belief of Innovative Interfaces is that we deliver an entire system. We deliver the hardware, the software, and the people.

Before a library receives its INNOVACQ, we work with the staff to decide what fields and codes are desirable for their system. We will help examine their. manual methods and make suggestions for on-line techniques. We will also help them set up all the tables in the system, although we do feel it is extremely important for each library to have the control and knowledge to manipulate their own system.

We are often there in the library when a new or possibly intricate procedure is to take place. For instance at the University of California at Riverside, INNOVACQ was installed during the middle of a fiscal year. Innovative Interfaces was there to help convert the current fiscal year, but we were also there when they went through the fiscal close and start-up of a new year.

CONCLUSlON

The five overall goals that were determined for the INNOVACQ may very well be those that you have as librarians. But how many of you would place your priorities as we did? In our priorities the underlying structure-the hardware, the database structure, the table-driven software-was the most important. These were critical areas that affected the entire performance of the system. As you look for a system for your library, your priorities may be in the features it offers. But in your examination of each system, take the time to look at its groundwork, for that may well tell you how best the system will accommodate you in the long run