College and Research Libraries l l L ALLEN B. VEANER Major Decision Points in Library Automation This art~cle !s based on. a longer, more detailed paper prepared for the 1970 Mtdwtnter Meettng of the Association of Research Libraries. Readers interes~ed in the complete text (with bibliography) are re- ferred to the M1nutes of the ARL meeting. The author discusses auto- ma;tion in the context of the management, facilities, and system re- qutrements for large research libraries. INTRODUCTION THE MAIN SUBJECT of this paper is change. Fundamental changes accompa- ny the automation of library functions. Whether one employs batch operations on-line techniques, or a mixture of th~ two, it constitutes a totally new way of life. When applied to a large central li- brary, automation creates the most radi- cal changes in library operations since the creation of libraries. This paper will not deal with single-application, small- scale automation efforts, nor with those in branch or special libraries. Rather it is addressed to the factors and decision points in developing a major program of automation in the main research facility of a large university or research organi- zation. The early questions in deciding upon an automation program are concerned with the implications of radical change. What is the status of the current manual system? Is the time right for a change? What are the known or anticipated ef- Dr. Veaner is Assistant Director for Bib- liographic Operations, Stanford University Libraries. The research reported in this pa- per was supported in part by U.S. Office of Education grant OEG-1-7-071145-4428. fects of major change upon the staff? Upon the faculty and students? What are the financial implications? Answers to these questions must be as detailed as possible and must be based on realistic expectations concerning the functions which are currently susceptible to auto- mation. What kinds of library activity can be automated in the present state of the art? Although much research and experi- mentation has been conducted on ad- vanced systems of infor~ation storage and retrieval, it is clear that there is nothing yet on the horizon to rival the human . brain and natural language for intellectual tasks of great complexity. Man is still the principal thinking crea- ture, the one who can handle ill-struc- tured problems and heuristic inquiry. But in the library he remains heavily burdened with routine tasks, or what is more accurately called formalizable work. We have enough experience to know that the activity currently susceptible to change through automation is this for- malizable, housekeeping work. Hence the candidates for automation are of two kinds: repetitive tasks and those jobs which are deterministic and highly struc- tured. They must involve relatively few intellectual decisions or decisions which are both repetitive and of a compara- /299 300 I College & Research Libraries • September 1970 tively lower order. ~'Is this number big- ger, equal to, or smaller than that one?" "Is this date earlier or later than anoth- er?" Formalizable activities are also the hardest to change because habit and custom govern their performance. Thus, immediately upon embarking on a study of automation, one enters a political thicket; at issue are performance norms, standardization, organizational structure and reporting patterns, job analysis, time and motion studies, reassignments, re- training, and the upsetting of all former social and occupational stability. In sum- mary, the question is: How well is an organization prepared for change? Is it willing to employ staff whose mission is challenge, evaluation, and program change? The methodology of introducing change has itself changed radically. Gone are the days of changing procedures by administrative memo or unilateral fiat. Intra-institutional competition for funds has become publi.~ knowledge and is forcing the revelation of administrative and economic realities which might pre- viously have remained behind the scenes. Ideally, a new system of doing any- thing should sell itself because those di- rectly affected by the change have al- ready fully participated in its develop- ment. This makes good sense because no level of staff will be unaffected by an automation program. Nevertheless, much work remains to alleviate the prevalent anxiety of job loss or takeover by ma- chines. Jacques Barzun stated not long ago that "mechanical work is the com- puter's meat; as a source of intelligence it is a total loss."1 In comparing the hu- man brain and the computer, Orlicky points out: When we discover areas of mental work in which we can outperform computers, we tend to regard computers as sluggish or clumsy, but perhaps a more proper way of looking at it would be to realize that the particular task is extremely difficult and that our own ability in this respect is out- standingly high. 2 Experiences of the past five years re- veal how remotely far we are from any miraculous software which will overnight transform our research libraries into ~Knowledge banks" capable of giving the right "answer" to any query, no matter how ineptly articulated. A basic assumption is that we have a finite amount of human and cash re- sources. A further assumption is that people-costs are rising much faster than unit machine-costs, while the productiv- ity of people in the library has hardly increased at all. A striking illustration of increased employee productivity in in- dustry is documented in a recent For- tune article on the Toyota Motor Com- pany of Japan.3 Here is how productiv- ity of Japanese automotive employees changed in twenty years: 1949: 1.5 cars/ year/ employee 1965: 20 cars/ year/employee 1968: 28 cars/year/employee We can demonstrate no such productiv- ity increases in libraries ; in fact, the op- posite is likely to occur. As long as total productivity is a linear function of the number of employees, more staff and more supervisors will always be needed to control the ever-growing intake of publications and the spreading demand for library services. Correspondingly, the more costly a resource of declining pro- ductivity, the greater the net cost of a given output. Unit processing costs in the library must inevitably increase un- less aided by machine processes. This fact and the universality of computers as a general purpose tool are the main force behind Dolby's contention that the computerization of cataloging is not only desirable but inevitable. 4 The administrator considering an au- tomation program faces two problems: ( 1) How does he allocate his limited re- sources? and ( 2) What can he do to in- 1 I J I I I I til j I I I I I I I l crease the productivity of his employees? Neither question can be answered with- out intimate knowledge of the present way of doing things. UNDERSTANDING THE PRESENT SYSTEM A prior requirement for any automa- tion activity is a thoroughgoing, com- prehensive analysis of systems and pro- cedures currently in force. It is essential that analysis be carried out without any preconceptions or prejudices for or against automation. The determination of unit costs and unit times, as well as peak loads, are among the most needed data for making any kind of management de- cision on the desirability or feasibility of making changes. It may be discovered that change is neither desirable nor eco- nomical in certain areas. The conduct of a detailed analysis and evaluation is in itself a major task which in a large li- brary can easily consume five to ten man- years. A systems effort is a continuing activ- ity, not something done once under the assumption that facts once obtained re- main stable and fixed. Systems analysis is also a full-time activity; it is impossible for any staff person charged with op- erations to conduct systems analysis. What should be the ratio of systems analysts to employees? If there are two support staff for each professional, it is probably reasonable to have one full- time analyst for each fifty persons on the technical processing staff, inclusive of file-oriented functions, such as circula- tion. However, this is merely suggestive, not prescriptive. Ideally, an analyst is a librarian, though excellent results can be obtained from a nonlibrarian if he meets the selection criteria described herein. ExTRA-LIBRARY AssrsTANCE The task of systems analysis and de- sign cannot be delegated to any group of outside "experts." The users play the "Afajor Decision Points I 301 crucial role in both analysis and design. Technical people bring their own preju- dices and a very imperfect knowledge of the mission and procedures of a given organization. In both business enterprise and in libraries, what can be delegated is programming and the technical meth- odology of implementing a system after management has decided what to do. Still, such contracted work will require constant monitoring by the systems ana- lyst/ designer and librarian to assure de- sign integrity. A team approach domi- nated by a high regard for the quality of interpersonal relations is essential to success. Where will the managerial talent come from to run an in-house development ef- fort? If a library "grows its own," the orientation and educational task will be minimized. If one must go to the outside, how will he merge bibliographic and computing talent in the same person? Suppose a library decides to delegate part or all of the technical (i.e., program- ming) task to an agency outside of the library. In this case, "outside the library" can just as well mean another agency on campus. A favorable political climate is a prerequisite to the success of this meth- od. Affiliation with a local research proj- ect in information retrieval or with a sci- entific computing center is attractive, be- cause there is a vast reservoir of intel- lectual talent-the scarcest resource in any automation task. However, such al- liances can be biased equally by re- search interests on the one hand and implementation interests on the other. The intellectual challenges behind tough software problems are the stuff of life for the best people-the only people you really want working on hard problems. In trying to find the most efficient logical solutions, a programmer can easily be de- flected from development aspects. A mu- tually challenging set of tasks should be determined which appeals to both sets of interests. To satisfy these conflicting 302 I College & Research Libraries • September 1970 motivations takes a project manager with unusual catholicity of perspective. PERSONNEL CHARACTERISTICS, SELECTION AND SALARIES When one decides to mount an in- house automation effort, how does he get help with staffing? Judging the talent and performance capability of software people is not within our normal exper- tise. Even the experts. have their troubles. Unless the librarian has learned a great deal about computing-possibly even learning some programming himself-he cannot reliably evaluate a candidate for systems analyst or programmer. You may recall that the ACLS report, On Re- search Libraries, closely parallels Orlic- ky's advice for businessmen, namely, that there is no alternative to the librarian's learning the computer art: Some programming experts must be brought into libraries but, more important, libra- rians must learn to use computers and must come to understand their strengths and limitations. This education process will take several years under the best conditions. From experience in other fields we can em- phasize that there is no alternative to li- brary experts learning computation. Any other course will lead to inferior results with great waste of money and effort. 5 We have no contraindications to this ad- vice. Librarians responsible for systems efforts must learn programming. We will nevertheless continue to depend upon knowledgeable people on campus, such as the staff of the scientific computa- tion center or the administrative data processing center. Such assistance will be valuable, however, only in proportion to the degree to which the librarian is capable of making his goals understand- able to these outsiders. About one man- year should be allotted for training and orienting each nonlibrarian sufficiently to ensure that the systems librarian can be confident that the details of a biblio- graphic application will be well under- stood. It is common to divide systems de- velopment staff into at least three cate- gories: systems programmers, applica- tions programmers, and systems analyst/ designers. Systems programmers work with and write the programs that offer to the applications programmers certain essential machine facilities , such as ter- minal access, special compilers, and lan- guages for writing applications programs. The applications programmer writes the programs which actually execute user defined tasks, such as printing catalog cards from MARC tapes, creating over- due notices, issuing purchase orders, and the like. The analyst/ designer is the per- son who gets right out with the users of the system and learns thoroughly their work. These categories of people are very different from each other; in most cases, it is not at all practicable to think about using them interchangeably. Because he interacts directly w ith the user, the analyst/ designer can make or break an application of automation. The analyst must be personable, patient, and respectful of the librarian's expertise. It is wise to be on guard against any candi- date who appears abrasive, "smart al- ecky," likely to intimidate, or who feels that he already knows or can learn with little effort all that there is to b e known about an application. Programmers are different. Some are gregarious and sociable, others are lon- ers. Most will prefer to work with the intellectual challenge of the application as described by an analyst rather than work directly with the user. E xperienced programmers and users hardly ever speak the same language and can often mis- understand each other when they do get together. The qualified systems analyst knows enough about both worlds to be an effective go-between. Systems development is expensive. A yardstick from industry indicates that it costs about $35,000 to support a systems programmer for one year. Suppose that he is paid $15,000; this might come to some $2,000 per month inclusive of over- head, to which is added his require- ments for machine test time. Machine time for testing might cost up to $1,500 per month, though he won't spend that much every month. His rate of expendi- ture will vary in accordance with task complexity and his own accuracy and efficiency, and, of course, in accordance with the pricing algorithm of the given installation. For library system develop- ment, I can cite one example. To de- velop the program for converting an in- coming MARC tape to Stanford's local, internal processing format cost $8,000 in man and machine resources, inclusive of overhead. These are development costs, not operating expenses. The estimation of machine costs requires explicit infor- mation on specific program steps, ma- chine configuration and pricing algo- rithms, the amount of execution time and utilization of other machine re- sources, the type of data being processed, and the general system complexity. An experienced cost accountant is really needed to interpret and break out the components of computer costs. The salaries commanded by high qual- ity analysts and programmers will come as no surprise. What may come as a shock is that one may have to pay more than one's own salary to recruit the right talent-this is particularly the case for large-scale applications which involve a degree of sophistication beyond normal batch processing. The larger the institu- tion, the higher must these salaries be, because bigger organizations inevitably · have more highly sophisticated com- puter services, which in turn require and attract higher-priced people. Sometimes one hears the complaint that there is a ''shortage" of qualified computer people when what one really means is that someone does not wish to pay the sal- aries necessary to attract the desired people, or some institutional or legal con- straint does not permit making the right offer. Major Decision Points I 303 FoRECASTING WHETHER AND WHAT To AuTOMATE A thorough analysis of current systems should provide the administrator with information on the flow of material and data, the allocation of personnel, the or- ganization, content, and use of files, and a complete inventory of forms. He will also obtain a profile of unit costs for various tasks within each library func- tion of each subsystem. Working togeth- er with the systems analyst, the pro- grammer, the staff of the computation center, and the policy makers of the university, the librarian should be able to identify not only the high unit-cost items and high total-cost items in this profile, but also those which are tech- nically feasible for and readily suscepti- ble to automation. There is no simple formula to define "readily susceptible to automation." This will be a function of the unique combination of machine and people resources present at a given in- stitution and the director's own priorities based upon his program. It may be that some of the high unit-cost items cannot be aided by automation in the present state of the art; similarly, there could be a number of low-cost functions which oc- cur in sufficient quantity to justify com- puter applications. For example, there is little doubt that circulation is one of the most profitable areas for exploration in any modern computer environment. But, at this time, the computer is likely to be of little immediate, economical aid to any intellectual task, e.g., original cata- loging. A good text editing system, though, can simplify and speed the cler- ical aspects of copy preparation and card production. There are three major, practical rea- sons for undertaking the automation of library functions: ( 1 ) to do something less expensively, more accurately, or more rapidly, ( 2) to do something which can no longer be done effectively in the manual system because of increased com- plexity or overwhelming volume of op- 304 I College & Research Libraries • September 1970 erations, and ( 3) to perform some func- tion which cannot now be performed in the manual system-providing always that the administrator actually wants to perform the new service, has the re- sources to pay for it, and is not en- dangering the performance of existing services for which/there is an established demand. : In this connection, the mere capability of performing . a given function by com- puter is not a sufficient reason for doing it. The technician is likely to believe "If we can do it, we should." The industri- alist will assert "If we can make a profit, we should do it." The director of the li- brary must decide whether that is the thing he really wishes to do in terms of his program, his budget, and his clien- tele. With regard to the difficulties of li- brary automation, an encouraging atti- tudinal shift is now evident. From a "trivial" problem, library automation has emerged as the intellectual challenge, ri- valing information retrieval. There is, of course, always a substantial distance be- tween the availability of a device and its actual application. Oettinger has out- lined carefully the long, arduous strug- gles between conception of a device or technique, the building and testing of prototypes, and their emergence into production. In discussing the properties of educational devices, he cites the fol- lowing factors to be considered in ap- plying innovative resources: flexibility, generality, parallelism of access and sim- plicity of scheduling, quantity available, physical accessibility, reliability, ease of maintenance, degree of complexity, com- fort for the user, and standardization. He also demolishes the idea ( so glibly pro- moted by hardware salesmen) that pos- session of a device is synonymous with change of habit. 6 Leaving aside practicality for a mo- ment, a fourth justification for library automation activity is research-to learn whether certain new functions can be carried out with computer assistance, and if so, how to do them. The library community should neither abrogate nor delegate its research responsibilities. However, it is advantageous to integrate a variety of talents in complex com- puter applications. The stimulus of the nonlibrarian working together with li- brarians can aid in making sure that we do not suffer from "tunnel vision" and try merely to apply the new technology in the context of present limitations. These dangers are well delineated in SDC' s report, Technology and Librar- ies.7 F AGILITIES: CHOICE, PRIORITY, TIME I~eally, the library ought to have un- der its own direct control all the neces- sary resources for complete system de- velopment. This is hardly ever achiev- able. The larger and the more complex the institution, the more likely is its com- puter facility to be complex and cen- tralized. Library use of computers suffers from two major handicaps: low priority for machine use and insufficient machine time. One way of dealing with these prob- lems is to buy a significant interest in the machine. Another is for a number of neighboring institutions to form a con- sortium or processing center, or to utilize commercial services. Where the work load of a single library may not suffice to interest a computer facility, combined purchasing power may carry more weight. Still another method for over- coming problems of priority and time re- lies on prior, local political settlements, but in the end this method may not be the most efficacious. A problem-oriented solution is always better, and a great deal of work needs doing on the formu- lation of appropriate problem-oriented strategies for gaining computer support in library automation. Libraries consume vast amounts of storage, use a lot of machine resources for input and output, such as keyboard- + ing purchase orders or collecting circula- tion transactions, printing catalog cards, and the like. Except for very complex software tasks, most library applications involve very little actual computing. They tend to be "input/ output bound" rather than ccprocessing bound," hence are much more closely allied to the op- erations of an administrative data proc- essing center than to a scie-ntific comput- ing center. However, it would be mis- leading to suggest that this mere sim- ilarity in itself will be productive if much experimentation is involved. Oettinger points out: As many computer centers of all kinds have found out to their despair, routine sched- uled administrative work and unpredictable experimental work coexist only very un- easily at best, and quite often to the seri- ous detriment of both. Where the demands of administrative data processing and edu- cation require the same facilities at precise- ly the same time, the argument is invari- ably won by whoever pays the bills. Fi- nances permitting, the loser sets up an in- dependent installation. s Turning to the scientific center, we see that its mission is to supply fast turnaround service to the research com- munity. Its management generally does not look favorably upon file-oriented ap- plications, because the machine over- head necessary to manage these functions detracts from the center's ability to ser- vice its clientele. Indeed, if there is any sophistication whatever in the scientific system, the number of competing users rises faster than the capacity of the sys- tem to meet demand, and this will cer- tainly affect adversely any application not within that center's mission. DEDICATED OR SHARED HARDWARE Dedicated hardware involves high fixed-costs of equipment and personnel; shared hardware involves high variable- costs for services performed, but if prop- er contracts have been negotiated, the user has some control over the kind and Major Decision Points I 305 amount of services he purchases. A con- venient feature of dedicated hardware is that the organization is beholden to no one-save the computer manufacturer, the telephone company, and the electric power company. But only one's own ap- plications can be run on the machine and questions of priority and sufficiency of time do not exist; in fact, one may have time to sell. The type of machine one can have all to oneself will probably be a stripped-down model with a limited repertoire of software ccsmarts," and ac- commodating few peripheral devices. A crew is needed to run the dedicated machine: operators to mount tapes, feed in decks of cards, and tear off and dis- tribute printouts; systems programmers to maintain local software and keep the manufacturer's software and documen- tation up-to-date; and an administrator to schedule utilization and maintenance. It is also handy to have an external work load for idle time to help pay the rent. Also required will be backup arrange- ments so that operations can function on another facility during planned or unplanned downtime. There are two very powerful argu- ments for not having one's own small computer: 1. First, a small taste of things one can do inevitably gives one an appetite for more sophisticated applications. The capability of the small machine is soon exhausted; changing to a larger comput- er may require a change in the operating system or programming language, either of which could require a lot of repro- gramming. 2. The second reason is that small ma- chines and small installations do not at- tract the intellectual talent needed to assure the most efficient use of machine resources. The better people naturally gravitate to the more sophisticated in- stallations. An alternative is to associate with a larger facility to take advantage of pe- ripheral storage, special output devices 306 I College & Research Libraries • September 1970 (such as terminals), and the scarce re- source-talent. Because very little calcu- lational computing is done in library ap- plications, it may be possible to satisfy a local need with a "mini-computer" if the small machine can be used as a ter- minal for the central facility. But this kind of interconnection or networking is a substantial software task in itself. Assuming that it is better to pay for service from a computation center, what kind of facility should be used? The differing job characteristics in scientific and administrative applications have al- ready been mentioned. Administrative data processing is oriented towards "fixed field" applications, whereas library usage involves variable length records with many special graphic characters. Administrative applications are further characterized by large work loads which often require two or three shifts; their timing schedules are critical owing to payroll and tax calculations and the month-end loads imposed by the task of preparing budget statements for thou- sands of cost centers. Also, an adminis- trative data processing center is general- ly about one software generation behind a scientific center, and its systems pro- grams may not be as efficient. However, an administrative center is likely to be much more sensitive to matters of file security. Ultimately, the research library looms as the largest continuous consumer of computer power on the campus. When that time comes, it is entirely conceiv- able that libraries may dominate the campus computer realm. No other agen- cy on campus affords more intellectual interaction with the academic communi- ty than does the library-which is exact- ly the reason why it is important for large libraries to continue experimenta- tion and research in library automa- tion. A failure aggressively to push re- search on bibliographic applications could lead to second-class computer fa- cilities, and could put libraries many years behind other research components of the academic community. NETWORKS Demonstrations of electronic network- ing have now become routine, but it would be misleading to believe that the establishment of regular, error-free net- working is just .around the corner. Exist- ing telephone networks were designed for voice communication, not data trans- mission. Much old equipment is still in use; even though electronic exchanges are being rapidly installed, it may be 1980 or later before new technology is fully applicable to land lines. And there are many companies competing for the production and marketing of "intercon- nect" equipment. Accompanying the junc- ture of telephone and nontelephone in- terests are issues of performance stan- dards, reliability, and technical stan- dards-including establishing national use of the new ANSI (formerly USASI) code for data interchange and telecom- munication. It is also apparent that the problems of networking, even in the lo- cal environment, are of no small intellec- tual and technical depth, and it would be folly to imagine that a large number of independent local networks are going to interact successfully on the first try. In all, many technical and economic hurdles remain; a common hope of all educational users is the planned educa- tional communication satellite which might assist in reducing transmission rates and increasing reliability. PRICING CoMPUTER SERVICES Exactly how one prices centrally fur- nished services is at times a matter of conjecture, but invariably one of contro- versy. The overhead cost of running a center is considerable-two and one-half to three times the straight hardware rent- als-and includes physical plant, hard- ware maintenance contracts, software maintenance, user education, large quan- tities of published documentation to pro- cure and maintain salaries and staff benefits, insurance for equipment, elec- tric power and air conditioning, full rent- al for equipment which may be only par- tially utilized, failsafe auxiliary power, paper, spare disc packs, telephone ser- vice, travel to computer conferences. Any time a peripheral device is at- tached to a computer, there is an asso- ciated software overhead. Someone ·has to write the software which makes that extra device work within the local soft- ware environment. Since each environ- ment is unique, the vendor's software is sometimes a square peg. That is why ev- ery computer center needs a ready sup- ply of systems programmers and why additional devices require payment of a surcharge or "installation fee." But un- like a telephone installation charge, the "installation fees" for computer periph- erals can never be one-time charges be·- cause computer systems are never static. Computer resources are a very pecu- liar quantity. In any installation, there is a finite and measurable amount of com- puting power, although the users would like to behave as though there were an infinite amount of the . resource. All pric- ing schemes are designed to ration the fixed resource in accord with the value of a particular service to a given user. Flexible pricing schemes have been de- vised to control the user's behavior in the hope of distributing equitably the costs of all available resources. Flexible pricing divorces pricing and costing, raising the price Qf some resources to pay for an associated resource, which if charged according to its true cost, would be prohibitively expensive for the user. The good pricing algorithms recover total operating costs inclusive of over- head. Thus, in a large scientific center which may be terminal oriented and whose mission is scientific data process- ing, there are two actions which slow down service to the majority of users: mounting tapes and changing forms in the printers. To discourage these activ- Major Decision Points I 307 ities a special service charge may be im- posed. Likewise, to balance the load on the machine (and to balance the budg- et), special low rates may be offered in the overnight service block or corre- sponding extra charges imposed during the day to run urgent jobs at a high priority. One more observation: Although unit machine costs are going down all the time, the more one has of a cheap re- source-like quick photocopying, for in- stance-the more one is likely to use it, and the net effect may be more money spent. It's the total expense that counts, not the unit cost. Consequently, the more facilities automation gives us, the more likely are we to need more resources rather than less. CHANGE As A WAY oF LIFE One final question on the use of a cen- tral facility: What protection does the user have if the central facility decides to change its hardware or software? A change is only inconvenient for the tran- sient research population but it is cata- strophic for any continuing function like the library or the administrative data processing center. Written negotiations may offer some protection, but these tend to be political and are never as satisfactory as problem-oriented solu-- tions. In any case, it would be self-de- ceptive to believe that any system de- sign can be frozen forever. Hardware and software will change continuously; the rate of change needs to be con- trolled and stabilized. Any major system - change will affect forms, files, personnel allocation, proce- dures, and organizational structure. A change in any of these areas involves a training responsibility for the systems staff plus appropriate sensitivity to inter- personal relations. TIME ScALE FOR SYSTEM DEVELOPMENT - What can one realistically expect con- cerning the time scale to design, install, 308 I College & Research Libraries • September 1970 and operate an automated library sub- system, such as circulation or acquisi- tion? Shoffner has pointed out that much early design work was based on the as- sumption-now known to be false-that existing library operations were already known in considerable detail.9 To pro- vide this detail in the form necessary for adequate system design work is very time-consuming, and the failure to real- ize the required time commitments is responsible for much of the slippage ob- served in current projects. Contrary to popular belief, the design and installation of a computerized sys- tem to perform a given function is any- thing but a mechanical process. Yet too many people still imagine that it is a simple, straightforward process to How chart an operation, write a program, and start running. Once a logically correct program has been written, it is true that its execution will be mechanical-if no equipment malfunction occurs. To be logically perfect, the program's intellect- ual design must account for every con- ceivable detail and alternative in the function being automated. This degree of perfection is hardly ever achieved the first time because of our lack of precise knowledge about our operations; it is here that we are confronted (rather brutally and expensively) by the con- ceptual error that everything there is to be known about a given library function is already known in complete detail. Programming bears a much closer re- semblance to space exploration or to a large building construction project, where unanticipated problems are constantly in- truding into well-laid plans. To reiterate: No computer system can be implemented in the absence of a se- ries of systematic prescriptions resolving in the minutest detail ali possible alterna- tives for all possible actions associated with a given application. The designers must have an exact picture in advance of the extent to which these minutiae must be described, documented, and in- corporated into a design before a single program can be written. Popular miscon- ception still talks about "what the com- puter will do," whereas the programmer knows the computer will insistently and stubbornly do only the things it has been instructed to do. The man-machine gulf is deep enough so that every program- mer wishes for an imaginary command or instruction for his computer: "Do what I mean, not what I said!" These remarks are not meant in disrespect of the research being conducted in artificial intelligence, simulation of the nervous system, and other advanced projects. The goals of those research projects are thousands, perhaps tens of thousands, of man-years away. Computers in a worka- day, production environment must still be told everything or they will do noth- ing. TRANSFERABILITY Since the inception of the computer era, transferability of software and sys- tem design has been a recurrent hope and theme. Theoretically, a program once written to perform a specific func- tion would not need to be written a sec- ond time by a second user. This hope has been dashed by four factors: 1. Scale of system complexity: The larger and more complex the system the more likely is it to have components that interact with the total system on that machine. There are relatively few prob- lems with the transfer of single-purpose batch programs or program modules, but even here, if data are to be processed by the transferred programs, it is essen- tial that the source data be identically formated and flagged. For this purpose, a translation program may be required. If there is much complexity to the data, less programming effort may be re- quired to start from scratch. (In actual fact, the last statement may not be true, but the programmer will have to be con- vinced.) 2. Machine incompatibilities from one l computer manufacturer to another, and even within the same vendor's line of equipment, and a lack of "upward com- patibility," a widely heralded feature which did not prove out in practice. En- gineering changes made to new ma- chines, if not incorporated into those al- ready in the field, introduce incompati- bilities within the same model of the same maker's computer. 3. A third deterrent to ready trans- ferability is local alteration of the ma- chine operating system and other sys- tem software, including use of different releases of compilers and languages. Changes in these "executive" programs, which run the computer or compile pro- grams, can often make application pro- grams inoperative. When system soft- ware is customized, subsystems no long- er function as interchangeable parts on physically identical machines. It be- comes a bit like trying to fit the door of a Chevrolet onto the body of a Plymouth; it can be done, but it isn't worth the ef- fort. 4. The fourth source of difficulty for transference of designs and programs lies in the fact that library X rarely wants to do exactly what library Y wants to do. As long as we insist upon tailoring the bibliographic record to a real or imag- ined special local need, there is little likelihood that the programs which process MARC tapes at one ·installation can process them elsewhere. Only the acceptance without change of a central- ly produced bibliographic record and the abandonment of customizing data to lo- cal requirements will enable system de- signers to begin thinking about one soft- ware package to work for many cus- tomers. AccEss TO MACHINE-READABLE FILES The structural complexity of biblio- graphic records and the semantic am- biguities associated with them greatly complicate the access task wherever there is no direct human intervention. Major Decision Points I 309 How, for instance, would a machine sys- tem distinguish the nearly 45,000 "Lon- don" entries in the Library of Congress Official Catalog? Even though these sub- tle intellectual problems have not yet been solved, experimental on-line sys- tems have demonstrated great power to retrieve references with far greater speed and much more flexibility than is afforded by manual systems. But we lack long -term experience with many users employing a large data base. Fur- ther, the dependability of on-line files for bibliographic applications has yet to be demonstrated in a production environ- ment, though I am reliably informed that the intellectual problems of file reliabil- ity and security may be near solution in several different commercial and military applications. The cost of maintaining in machine-readable form large files subject to immediate on-line access is prohibi- tive right now but could be within reach for technical processing applications of large libraries or groups of libraries, if economic and technical solutions can be found for networking problems. (Costs of file maintenance for large manual files in large libraries should be monitored continuously to see if a breakeven point is nearing which could justify selective change to machine-readable files with reasonable prospects of near-term pay- off.) Yet why keep available on-line very large files where the probability of ac- cess to a given item is exceedingly small? We know little about how users access bibliographic information from printed media and still less about how they might extract data from other kinds of files. Considerable prior experimentation with large, machine-readable files is necessary if we are to know how to organize those files. Even so, use of the files after a peri- od of time might very well result in a continuously changing file structure, which, ideally, should be transparent to the user, i.e., apparent and meaningful only to the systems programmers. In the 310 I College & Research Libraries • September 1970 future we probably need to be prepared for partitioned files with different tech- nical designs and differing echelons of accessibility, ranging from printed media through on-line indexes and computer- output-microfilm (COM) files. Parti- tioned files might range from on-line in- dexes, through off-line book catalogs, special chronological or subject files, COM catalogs reissued yearly with cur- rent updates available from small on- line files. This variety of products and services can only be envisaged because of the richness of the MARC II format, which affords great selectivity of data elements for the user. By selective omis- sions, we can conceive of a graded series of files whose complexity and access time are inversely related, with appro- priate cost trade-offs. New ideas for file organization and access are badly need- ed; all will have to be tested for eco- nomic and technical practicality and user acceptance. The cheapest method of accessing a static, little-used file is via a printed me- dium. Interest in on-line library files has undoubtedly been stimulated by success- ful commercial applications, some of which parallel library uses. Airline and hotel reservation systems are good ex- amples of successful on-line applications and rapid file accessibility. Both deal with an extremely perishable commodi- ty. The same is true of industrial parts lists and inventory control systems, where orders and cash How are the controlled items. How perishable is bibliographic information? A fairly good case can surely be made for the perishability of tech- nical processing or circulation data, which by definition are high activity, "update-intensive" files. The case is like- ly to be somewhat weaker right now for low activity files. How much is the user willing to pay for immediate access to a file? Suppose one can satisfy 85 percent of the over-the-counter circulation queries by means of a batch system with 24- hour turnaround, as is the case at Co- lumbia University?10 What would be the value of a more sophisticated system which might reduce turnaround to an hour? To a minute? Suppose it costs twice as much to reduce turnaround to an hour? Five times as much to cut it to a few seconds? If automation is to be cost-effective, the resource must be ap- propriately matched to the task at hand. But in this connection it is well to keep in mind the rapid development characteristic of computer technology. Fast-response, large-capacity storage de- vices may be available sooner than one imagines. What looks impossibly expen- sive or beyond reach today can easily become tomorrow's necessity. Continu- ous contact with technical developments is an indispensable part of the system librarian's responsibility. CoMMUNICATION AND DocuMENTATION Without proper documentation, a job is not finished, and the systems analysis work, design, and programming are use- less. There are five purposes to documen- tation: To make progress visible to one's spon- sor. To communicate one's intellectual product in the absence of its creators. To communicate designs-for staff knowledge and participation-from the moment of conception through all formal design steps, terminating in completely coded, working programs. To record the reasons for specific logi- cal decisions and design features so that the originator does not have to depend upon memory in the course of revising or debugging designs and programs. To communicate project results to the outside world. Documentation does not fall out auto- matically as a by-product of a system development effort; it requires rigorous discipline. Unfortunately, there is noth- ing inherently romantic or fascinating about report writing; it is a burden. The provision of adequate documentation re- quires first a person who can write in clear, articulate English and who under- stands both computers and libraries. These people are expensive. A project with a staff of five professionals should at least consider having a full-time edi- tor to relieve the principal investigator of extensive report writing. If the profes- sional staff is ten or more, an editor is in- dispensable. NATIONAL GOALS AND PRIORITIES Institutional uniqueness is a character- istic of current library automation activi- ty. Each library appears to be going its own way, applying automation in much the same fashion as it applies conven- tional methodology. There is little agree- ment on what to do, in what sequence it should be done, and how we should do it. In short, we lack a national plan for dealing with the intellectual and managerial problems of library automa- tion efforts. Our current endeavors-save for establishment of the MARC II stan- dard format-are as fragmented as the manual systems they are intended to re- place. Do we want to create a series of incompatible, local efforts? How can we resolve the inevitable conflicts of inter- est among institutions of differing sizes, budgets, and academic programs repre- sented within a given group? Joseph Becker suggests that some form of "social engineering" is needed to make it easier for large research libraries to contract among themselves for major systems development. Of course, such a suggestion implies a far greater commit- ment to standardization than the library community has evidenced to date. It must be remembered that fundamental- ly libraries are in the communication business. Efficient communication is completely dependent upon standardi- zation-a fact that is being focused by the machine's intolerance for ambiguity. When we leave our oldest and tradi- tional "software" -natural language and Major Decision Points I 311 the written word-to take up the elec- tronic impulse, we enter a world of un- forgiving, impersonal rigor. To make the change successfully, it is doubtful that we can continue to go our separate ways as we have so expensively done with cat- aloging and classification. We have given up self-sufficiency in collection building; will we give up some local autonomy in technical processing to benefit from the economies of stan- dardization? My fear is that if we do not, we shall have fewer and fewer re- sources remaining for service to our clientele. This is a special hazard as li- braries-especially in private institutions -enter a period of increased budget visibility. By some means, the desired and needed national goals and priorities must be identified; if we do not do it, it may be done for us. Neither we nor our users may care for the results. CoNCLUSION Librarians have succeeded in demon- strating that a variety of library tech- nical processing and public service op- erations can be computer aided. Signifi- cant accomplishments have occurred with relatively modest investments. Though few institutions can yet directly utilize anyone else's efforts, we are prob- ably no different from the computer world at large in this respect. Both worlds may be suffering from lack of a national plan. These national policy is- sues-standards, program priorities, the kinds and d egrees of bibliographic ac- cess, and some concerted attack on the economic problems surrounding com- puter applications-still await solution. It is my conviction that the solution of these problems is essential in order that research libraries may be able to service the present and future requirements of their users. The full scope of the prob- lems of library automation is just be- ginning to b e realized. Now is the time to marshal the country's best brains and resources in response to the recommenda- 312 I College & Research Libraries • September 1970 tions of the National Advisory Commis- define the problem; that is significant sion on Libraries. We are beginning to progress. rl REFERENCES 1. Jacques Barzun, "New Librarian to the Rescue," Library ] ournal 94: 3964 ( 1 Nov. 1969). 2. Joseph Orlicky, The Successful Com- puter System: Its Planning, Develop- ment and Management in a Business Enterprise. (New York: McGraw-Hill, 1969), p.21. 3. William Simon Rukeyser, "The World's Fastest-Growing Auto Company," For- tune v. 80, no. 7 (December 1969): 76-80 and 128-35. 4. James L. Dolby, V. J. Forsyth, and R. L. Resnikoff, Computerized Library Catalogs: Their Growth, Cost, and Utility (Cambridge: M.I.T. Press, 1969), p.16. 5. Max V. Mathews and W. Stanley Brown, "Research Libraries and the New Technology," On Research Li- braries (Cambridge: M.I.T. Press, 1969)' p.65. 6. Anthony G. Oettinger, Run, Computer, Run. (Cambridge: Harvard Univ. Press, 1969), p.44. . 7. Carlos A. Cuadra, ed., Technology and Libraries (Santa Monica: System De- velopment Corp., 1967). (Available as ERIC Document ED 022 481). -8. Oettinger, Run, Computer, Run, p.196. 9. Ralph J\1. Shoffner, "Economics of Na- tional Automation of Libraries," Li- brary Trends v. 18 no. 4 (April1970): 448-63. 10. Paul J. Fasana. (Personal communica- tion to the author.)