75 THE DEVELOPMENT AND ADMINISTRATION OF AUTOMATED SYSTEMS IN ACADEMIC LIBRARIES Richard DE GENNARO: Harvard University Library, Cambridge, Mass. The first part of this paper considers three general approaches to the development of an automation program in a large research library. The library may decide simply to wait for developments; it may attempt to develop a total or integrated system from the start; or it may adopt an evolutionary approach leading to an integrated system. Outside consult- ants, it is suggested, will become increasingly important. The second part of the paper deals with important elements in any program regardless of the approach. These include the building of a capability to do auto- mation work, staffing, equipment, organizational structure, selection of projects, and costs. Since most computer-based systems in academic libraries at the present time are in the developmen tal or early operational stages when improve- ments and modifications are frequent, it is difficult to make a meaningful separation between the developmental function and the administrative or management function. Development, administration, and operations are all bound up together and are in most cases carried on by the same staff. This situation will change in time, but it seems safe to assume that automated library systems will continue to be characterized by instability and change for the next several years. In any case, this paper will not attempt to distinguish between developmental and administrative ftmc- tions but will instead discuss in an informal and non-technical way some of the factors to be considered b y librarians and administrators when 76 Journal of Library Automation Vol. 1/ 1 March, 1968 their thoughts turn, as they inevitably must, to introducing computer systems into their libraries or to expanding existing machine operations. Alternative approaches to library automation will be explored first. There will follow a discussion of some of the important elements that go into a successful program, such as building a capability, a staff, and an organization. The selection of specific projects and the matter of costs will also be covered briefly. APPROACHES TO LIBRARY AUTOMATION Devising a plan for automating a library is not entirely unlike formu- lating a program for a new library building. While there are general types of building best suited to the requirements of different types of library, each library is unique in some respects, and requires a building which is especially designed for its own particular needs and situation. As there are no canned library building programs, so there are no canned library automation programs, at least not at this stage of development; therefore the first task of a library administration is to formulate an approach to automation based on a realistic assessment of the institution• s needs and resources. Certain newly-founded university libraries such as Florida Atlantic, which have small book collections and little existing bibliographical ap- paratus, have taken the seemingly logical course of attempting to design and install integrated computer-based systems for all library operations. Certain special libraries with limited collections and a flexible bibligraphi- cal apparatus are also following this course. Project INTREX at M.I.T. is setting up an experimental library operation parallel to the traditional one, with the hope that the former will eventually transform or even supersede the latter. Several older university libraries, including Chicago, Washington State, and Stanford, are attempting to design total systems based on on-line technology and to implement these systems in modules. Many other university libraries (British Columbia, Harvard, and Yale to name only a few) approach automation in an evolutionary way and are designing separate, but related, batch-processing systems for various housekeeping functions such as circulation, ordering and accounting, cata- log input, and card production. Still other libraries (Princeton is a notable example) expect to take little or no action until national standardized bibliographical formats have been promulgated, and some order or pat- tern has begun to emerge from the experimental work that is in progress. Only time will tell which of these courses will be most fruitful. Meanwhile the library administrator must decide what approach to take; and the approach to automation, like that to a building program, must be based on local requirements and available resources ( 1,2). For the sake of this discussion the major principal approaches will be considered under three headings: 1) the wait-for-developments approach, Automated Systems in Academic Libraries/ DE GENNARO 77 2) the direct approach to a total system, and 3) the evolutionary ap- proach to a total system. The use of outside consultants will also be discussed. The Wait-For-Developments Approach This approach is based on the premise that practically all computer- based library systems are in an experimental or research-and-develop- ment stage with questionable economic justification, and that it is un- necessary and uneconomical for every library to undertake difficult and costly development work. The advocates of this approach suggest that library automation should not be a moon race and say that it makes sense to wait until the pioneers have developed some standardized, workable, and economical systems which can be installed and operated in other libraries at a reasonable cost. For many libraries, particularly the smaller ones, this is a reasonable position to take for the next few years. It is a cautious approach which minimizes costs and risks. For the larger libraries, however, it overlooks the fact that soon, in order to cope with increasing workloads, they will have to develop the capability to select, adapt, implement, operate, and maintain systems that were developed elsewhere. The development of this capability will take time and will be made more· difficult by the absence of any prior interest and activity in automation within the adapt- ing institution. The costs will be postponed and perhaps reduced because the late-starters will be able to telescope much of the process, like coun- tries which had their industrial revolution late. However, it will take some courage and political astuteness for a library administrator to hold firmly to this position in the face of the pressures to automate that are coming from all quarters, both inside and outside the institution ( 3). A major error in the wait-for-developments approach is the assumption that a time will come when the library automation situation will have shaken down and stabilized so that one can move into the field confi- dently. This probably will not happen for many years, if it happens at all, for with each new development there is another more promising one just over the horizon. How long does one wait for the perfect system to be developed so that it can be easily "plugged in," and how does one recognize that system when one sees it? There is real danger of being left behind in this position, and a large library may then find it difficult indeed to catch up. The Direct Approach To A Total System This approach to library automation is based on the premise that, since a library is a total operating unit and all its varied operations are inter- related and interconnected, the logic of the situation demands that it be looked upon as a whole by the systems designers and that a single inte- 78 Journal of Library Automation Vol. 1/ 1 March, 1968 grated or total system be designed to include all machinable operations in the library. Such a system would make the most efficient and eco- nomical use of the capabilities of the computer. This does not require that the entire system be designed and implemented at the same time, but permits treating each task as one of a series of modules, each of which can be implemented separately, though designed as part of a whole. Several large libraries have chosen this method and, while a good deal of progress is being made, these efforts are still in the early develop- ment stage. The University of Chicago system is the most advanced (4) . Unlike the evolutionary approach, which assumes that much can be done with local funds, home-grown staff, batch processing and even sec- ond generation computers, the total systems approach must be based on sophisticated on-line as well as batch-processing equipment. This equip- ment is expensive; it is also complex, requiring a trained and experienced staff of systems people and expert programmers to design, implement, and operate it effectively. Since the development costs involved in this approach are considerable, exceeding the available resources of even the larger libraries, those libraries that are attempting this method have sought and received sizable financial backing from the granting agencies. The total systems approach has logic in its favor: it focuses on the right goal and the goal will ultimately be attainable. The chief difficulty, however, is one of timing. The designers of these systems are trying to telescope the development process by skipping an intermediate stage in which the many old manual systems would have been converted to simple batch-processing or off-line computer systems, and the experience and knowledge thus acquired utilized in taking the design one step further into a sophisticated, total system using both on-line and batch-processing techniques. The problem is that we neither fully understand the present manual systems nor the implications of the new advanced ones. We are pushing forward the frontiers of both library automation and computer technology. It may well be that the gamble will pay off, but it is extremely doubtful that the first models of a total library system will be economi- cally and technically viable. The best that can be hoped for is that they will work well enough to serve as prototypes for later models. While bold attempts to make a total system will unquestionably ad- vance the cause of library automation in general, the pioneering libraries may very well suffer serious setbacks in the process, and the prudent administrator should carefully weigh the risks and the gains of this ap- proach for his own particular library. The Evolutionary Approach To A Total System This approach consists basically of taking a long-range, conservative view of the problem of automating a large, complex library. The ultimate goal is the same as that of the total systems approach described in the Automated Systems in Academic Libraries/DE GENNARO 79 preceding section, but the method of reaching it is different. In the total systems approach, objectives are defined, missions for reaching those ob- jectives are designed, and the missions are computerized, usually in a series of modules. In the evolutionary approach, the library moves from traditional manual systems to increasingly complex machine systems in successive stages to achieve a total system with the least expenditure of effort and money and with the least disruption of current operations and services ( 5 ) . In the first stage the library undertakes to design and implement a series of basic systems to computerize various procedures using its own staff and available equipment. This is something of a bootstrap operation, the basic idea of which is to raise the level of operation - circulation, acquisitions, catalog input, etc. -from existing manual systems to simple and economical machine systems until major portions of the conventional systems have been computerized. In the process of doing this, the library will have built up a trained staff, a data processing department or unit with a regular budget, some equipment, and a space in which to work: in short, an in-house capa- bility to carry on complex systems work. During this first stage the library will have been working with tried and tested equipment and software packages - probably of the second generation variety - and mean- while, third generation computers with on-line and time-sharing software are being debugged and made ready for use in actual operating situations. At some point the library itself, computer hardware and software, and the state of the library automation art will all have advanced to a point where it will be feasible to undertake the task of redesigning the simple stage-one systems into a new integrated stage-two system which builds upon the designs and operating experience obtained with the earlier sys- tems. These stage-one systems will have been, for the most part, mecha- nized versions of the old manual systems; but the stage-two systems, since they are a step removed from the manual ones, can be designed to incorporate significant departures from the old way of doing things and take advantage of the capabilities of the advanced equipment and software that will be used. The design, programming, and implementa- tion of these stage-two systems will be facilitated by the fact that the library is going from one logical machine system to another, rather than from primitive unformalized manual systems to highly complex machine systems in one step. Because existing manual systems in libraries produce no hard statistical data about the nature and number of transactions handled, stage-one ma- chine systems have had to be designed without benefit of this essential data. However, even the simplest machine systems can be made to pro- duce a wide variety of statistical data which can be used to great advan- tage by the designers of stage-two systems. The participation of non- 80 Journal of Library Automation Vol. 1/ 1 March, 1968 library-oriented computer people in stage-two design will also ·be facili- tated by the fact that they will be dealing with formalized machine sys- tems and records in machine readable form with which they can easily cope. While the old stage one of library automation was one in which librar- ians almost exclusively did the design and programming, it is doubtful that stage-two systems can or should be done without the active aid of computer specialists. In stage one it was easier for librarians to learn com- puting and to do the job themselves than it was to teach computer people about the old manual systems and the job to be done to convert them. This may no longer be the case in dealing with redesign of old machine systems into very complex systems to run on third or fourth generation equipment in an on-line, time-sharing environment. There is now a gen- eration of experienced computer-oriented librarians capable of specifying the job to be done and knowledgeable enough to judge the quality of the work that has been done by the experts. There is no reason why a team of librarians and computer experts should not be able to work ef- fectively together to design and implement future library systems. As traditional library systems are replaced by machine systems, the special- ized knowledge of them becomes superfluous, and it was this type of knowledge that used to distinguish the librarian from the computer expert. Just as there is a growing corps of librarians specializing in computer work, so there is a growing corps of computer people specializing in li- brary work. It is with these two groups working together as a team that the hope of the future lies. The question of who is to do library automa- tion - librarians or computer experts - is no longer meaningful; library automation will be done by persons who are knowledgeable about it and who are deeply committed to it as a specialty; whether they have ap- proached it through a background of librarianship or technology will be of little consequence. Experience has shown that computer people who have made a full-time commitment to the field of library automation have done some of the best work to date. Stage-two, or advanced integrated library systems, may be built by a team of library and computer people of various types working as staff members of the library, as has been suggested in the preceding discussion, but this approach also has its weaknesses. For example, let us assume that a large library has finally brought itself through stage one and is now planning to enter the second stage. It may have acquired a good deal of the capability to do advanced work, but its staff may be too small and too inexperienced in certain aspects of the work to undertake the major task of planning, designing, and implementing a new integrated system. Additional expert help may be needed, but only on a temporary basis during the planning and design stages. Such people will be hard to find, and also hard to hire within some library salary structures. They Automated Systems in Academic Librari-es/ DE GENNARO 81 will be difficult to absorb into the library's existing staff, administrative, and physical framework. They may also be difficult to separate from the staff when they are no longer needed. USE OF OUTSIDE CONSULTANTS There are alternative approaches to creating advanced automated sys- tems. The discussion that follows will deal with one of the most obvious: to contract much of the work out to private research and development firms specializing in library systems. What comes to mind here is an analogy with the employment of spe- cialized talents of architects, engineers, and construction companies in planning and building very large, complex and costly library buildings, which are then turned over to librarians to operate. When a decision has been made to build a new building, the university architect is not called in to do the job, nor is an architect added to the library staff, nor are li- brarians on the staff trained to become architects and engineers qualified to design and supervise the construction of the building. Most libraries have on their staffs one or two librarians who are experienced and knowl- edgeable enough to determine the over-all requirements of the new build- ing, and together they develop a building program which outlines the general concept of the building and specifies various requirements. A qualified professional architect is commissioned to translate the program into preliminary drawings, and there follows a continuing dialogue be- tween the architect and the librarians which eventually produces accept- able working drawings of a building based on the original program. For tasks outside his area of competence, the architect in turn engages the services of various specialists, such as structural and heating and venti- lating engineers. Both the architect and the owners can also call on library consultants for help and advice if needed. The architect participates in the selection of a construction company to do the actual building and is responsible for supervic;ing the work and making sure that the building is constructed according to plans and contracts. Upon completion, the building is turned over to the owners, and the librarians move in and operate it and see to its maintenance. In time, various changes and additions will have to be made. Minor ones can be made by the regular buildings staff of the insti- tution, but major ones will probably be made with the advice and assist- ance of the original architect or some other. In the analogous situation, the library would have its own experienced systems unit or group capable of formulating a concept and drawing up a written program specifying the goals and requirements of the automated system. A qualified "architect" for the system would be engaged in the form of a small firm of systems consultants specializing or experienced in library systems work. Their task, like the architect's, would be to turn 82 Journal of Library Automation Vol. 1/ 1 March, 1968 the general program into a detailed system design with the full aid and participation of the local library systems group. This group would be ex- perienced and competent enough to make sure that the consultants really understood the program and were working in harmony with it. Mter an acceptable design had emerged from this dialogue, the consultant would be asked to help select a systems development firm which would play a role similar to that of the construction company in the analog: to com- plete the very detailed design work and .to do the programming and de- bugging and implementation of the system. The consultant would over- see this work, just as the architect oversees the construction of a building. The local library group will have actively participated in the develop- ment and implementation of the system and would thus be competent to accept, operate, maintain and improve it. Success or failure in this approach to advanced library automation will depend to a large extent on the competence of the "architect" or consult- ant who is engaged. Until recently this was not a very promising route to take for several reasons. There were no firms or consultants with the requisite knowledge and experience in library systems, and the state of the library automation art was confused and lacking in clear h·ends or direction. It was generally felt tl1at batch-processing systems on second and even third generation computing equipment could and should be designed and installed by local staff in order to give them necessary ex- perience and to avoid the failures that could come from systems designed outside the library. Library automation has evolved to a point where there is a real need for advanced library systems competence that can be called upon in the way that has been suggested, and individuals and firms will appear to satisfy that need. It is very likely, however, that the knowledge and the experience that is now being obtained in on-line systems by pioneering libraries such as the University of Chicago, Washington State University and Stanford University, will have to be assimilated before we can expect competent consultants to emerge. The chief difficulty with the architect-and-building analog is that while the process of designing and constructing library buildings is widely un- derstood, there being hundreds of examples of library buildings which can be observed and studied as precedents, the total on-line library sys- tem has yet to be designed and tested. There are no precedents and no examples; we are in the position of asking the "architect'' to design a prototype system, and therein lies the risk. Mter this task has been done several times, librarians can begin to shop around for experienced and competent "architects" and successful operating systems which can be adapted to their needs. The key problem here, as always in library auto- mation, is one of correct timing: to embark on a line of development - Automated Systems in Academic Libraries/DE GENNARO 83 only when the state of the art is sufficiently advanced and the time is ripe for a particular new development. BUILDING THE CAPABILITY FOR AUTOMATION Regardless of the approach that is selected, there are certain prerequi- sites to a successful automation effort, and these can be grouped under the rubric of "building the capability." To build this capability requires time and money. It consists of a staff, equipment, space, an organization with a regular budget, and a certain amount of know-how which is gen- erally obtained by doing a series of projects. Success depends to a large extent on how well these resources are utilized, i.e. on the overall sh·ategy and the nature and timing of the vari- ous moves that are made. Much has already been said about building the capability in the discussion on the approaches to automation, and what follows is an expansion of some points that have been made and a re- capitulation of others. Staff Since nothing gets done without people, it follows that assembling, training, and holding a competent staff is the most important single ele- ment in a library's automation effort. The number of trained and experi- enced library systems people is still extremely small in ·relation to the ever-growing need and demand. To attract an experienced computer li- brarian and even to hold an inexperienced one with good potential, li- braries will have to pay more than they pay members of the staff with comparable experience in other lines of library work. This is simply the law of supply and demand at work. To attract people from the computer field will by the same token require even higher salaries. In addition, library systems staff, because of the rate of development of the field and the way in which new information is communicated, will have to be given more time and funds for training courses and for travel and attendance at conferences than has been the case for other library staff. The question of who will do library automation-librarians or computer experts-has already been touched upon in another context, but it is worth emphasizing the point that there is no unequivocal answer. There are many librarians who have acquired the necessary computer expertise and many computer people who have acquired the necessary knowledge of library functions. The real key to the problem is to get people who are totally committed to library automation whatever their background. Computer people on temporary loan from a computing center may be poor risks, since their professional commitment is to the computer world rather than that of the library. They are paid and promoted by the com- puting center and their primary loyalty is necessarily to that employer. Computer people, like the rest of us, give their best to tasks which they find interesting and challenging, and by and large, they tend to look l 84 Journal of Library Automation Vol. 1/ 1 March, 1968 upon the computerization of library housekeeping tasks as trivial and un- worthy of their efforts. On the other hand, a first-rate computer person who has elected to specialize in library automation and who has accepted a position on a library staff may be a good risk, because he will quickly take on many of the characteristics of a librarian yet without becoming burdened by the full weight of the conventional wisdom that librarians are condemned to carry. The ideal situation is to have a staff large enough to include a mixture of both types, so that each will profit by the special knowledge and experience of the other. To bring in computer experts inexperienced in library matters to auto- mate a large and complex library without the active participation of the library's own systems people is to invite almost certain failure. Outsiders, no matter how competent, tend to underestimate the magnitude and com- plexity of library operations; this is tme not only of computing center people but also of independent research and development firms. A library automation group can include several different types of per- sons with very different kinds and levels of qualifications. The project director or administrative head should preferably be an imaginative and experienced librarian who has acquired experience with electronic data processing equipment and techniques, and an over-all view of the gen- eral state of the library automation art, including its potential and direc- tion of development. There are various levels of library systems analysts and programmers, and the number and type needed will depend on the approach and the stage of a particular library's automation effort. The critical factor is not numbers but quality. There are many cases where one or two inspired and energetic systems people have far surpassed the efforts of much larger groups in both quality and quantity of work. Some of the most effective library automation work has been done by the people who com- bine the abilities of the systems analyst with those of the expert program- mer and are capable of doing a complete project themselves. A library that has one or two really gifted systems people of this type and permits them to work at their maximum is well on the way to a successful auto- mation effort. As a library begins to move into development of on-line systems, it will need specialist programmers in addition to the systems analysts described above. These programmers need not be, and probably will not be, librar- ians. Other members of the team, again depending on the projects, will be librarians who are at home in the computer environment but who will be doing the more traditional types of work, such as tagging and editing machine catalog records. In any consideration of library automation staff, it would be a mistake to underestimate the importance of the role of keypunchers, paper tape Automated Systems in Academic Libraries/DE GENNARO 85 typists, and other machine operators; it is essential that these staff mem- bers be conscientious and motivated persons. They are responsible for the quality and quantity of the input, and therefore of the output, and they can frequently do much to make or break a system. A good deal of discussion and experimentation has gone into the question of the relative efficiency of various keyboarding devices for library input, but little con- sideration is given to the human operators of the equipment. Experience shows that there can be large variations in the speed and accuracy of different persons doing the same type of work on the same machine. Equipment One of the lessons of library automation learned during the last few years is that a library cannot risk putting its critical computer-based systems onto equipment over which it has no control. This does not neces- sarily mean that it needs its own in-house computer. However, if it plans to rely on equipment under the administrative control of others, such as the computer center or the administrative data processing unit, it must get firm and binding commitments for time, and must have a voice in the type and configuration of equipment to be made available. The im- portance of this point may be overlooked during an initial development period, when the library's need for time is minimal and flexible; it be- comes extremely critical when systems such as acquisitions and . circula- tion become totally dependent on computers. People at university computing centers are generally oriented toward scientific and research users and in a tight situation wiU give the library's needs second priority; those in administrative data process~g, because they are operations oriented, tend to have a somewhat better appreciation of the library's requirements. In any case, a library needs more than the expressed sympathy and goodwill of those who control the computing equipment-it needs firm commitments. For all but the largest libraries, the economics of present-day computer applications in libraries make it virtually impossible to justify an in-house machine of the capacity libraries will need, dedicated solely or largely to library uses. Even the larger libraries will find it extremely difficult to justify a high-discount second generation machine or a small third gen- eration machine during the period when their systems are being devel- oped and implemented a step or a module at a time. Eventually, library use may increase to a point where the in-house machine will pay for itself, but during the interim period the situation will be uneconomical unless other users can be found to share the cost. In the immediate future, most libraries will have to depend on equipment located in computing or data processing centers. The recent experience of the University of Chicago Library, which is pioneering on-line systems, suggests that this situation is inevitable, given the high core requirements and low com- 86 Journal of Library Automation Vol. 1/ 1 March, 1968 puter usage of library systems. Experience at the University of Missouri ( 6), suggests that the future will see several libraries grouping to share a machine dedicated to library use; this may well be preferable to having to share with research and scientific users elsewhere within the univer- sity. A clear trend is not yet evident, but it seems reasonable to suppose that in the next few years sharing of one kind or another will be more common than having machines wholly assigned to a single library; and that local situations will dictate a variety of arrangements. While it is clear that the future of library automation lies in third-gen- eration computers, much of their promise is as yet unfulfilled, and it would be premature at this point to write off some of the old, reliable, second-generation batch-processing machines. The IBM 1401, for exam- ple, is extremely well suited for many library uses, particularly printing and formatting, and it is a machine easily mastered by the uninitiated. This old workhorse will be with us for several more years before it is retired to Majorca along with obsolete Paris taxis. Organization When automation activity in a library has progressed to a point where the systems group consists of several permanent professionals and several clericals, it may be advisable to make a permanent place for the group in the library's regular organizational structure. The best arrangement might be to form a separate unit or department on an equal footing with the traditional departments such as Acquisitions, Cataloging, and Public Services. This Systems Department would have a two-fold function: it would develop new systems and operate implemented systems; and it would bring together for maximum economy and efficiency most of the library's data processing equipment and systems staff. It will require ade- quate space of its own and- above all- a regular budget, so that per- manent and long-term programs can be developed and sustained on some thing other than an ad hoc basis. There are other advantages to having an established systems depart- ment or unit. It gives a sense of identity and esprit to the staff; and it enables them to work more effectively with other departments and to be accepted by them as a permanent fact of life in the library, thereby di- minishing resistance to automation. Let there be no mistake about it - the systems group will be a permanent and growing part of the library staff, because there is no such thing as a finished, stable system. (There is a saying in the computer field which goes "If it works, it's obsolete.") The systems unit should be kept flexible and creative. It should not be allowed to become totally preoccupied with routine operations and submerged in its day-to-day workload, as is too frequently the case with the traditional departments, which consequently lose their capacity to see their operations clearly and to innovate. Part of the systems effort Automated Systems in Academic Libraries/DE GENNARO 87 must be devoted to operational systems, but another part should be de- voted to the formulation and development of new projects. The creative staff should not be wasted running routine operations . . . There has never been any tradition for research and development work in libraries - they were considered exclusively service and operational institutions. The advent of the new technology is forcing a change in this traditional attitude in some of the larger and more innovative libraries which are doing some research and a good deal of development. It is worth noting that a concomitant of research and development is a certain amount of risk but that, while there is no such thing as change without risk, standing pat is also a gamble. Not every idea will succeed and we must learn to accept failures, but the experiments must be conducted so as to minimize the effect of failure on actual library operations. ·Automated systems are never finished - they are open-ended. They are always being changed, enlarged, and improved; and program and system maintenance will consequently be a permanent activity. This is one of the chief reasons why the equipment and the systems group should be concentrated in a separate department. The contrary case, namely dispersion of the operational aspects among the departments responsible for the work, may be feasible in the future as library automation becomes more sophisticated and peripheral equipment becomes less expensive, but the odds at this time appear to favor greater centralization. · The Harvard University Library has created, with good results, a new major department along the lines suggested above, except that it also in- cludes the photo-reproduction services. The combination of data process- ing and reprography in a single department is a natural and logical rela- tionship and one which will have increasingly important implications as both technologies develop concurrently and with increasing interdepend- ence in the future. Even at the present time, there is sufficient relation- ship between them so that the marriage is fruitful and in no way prema- ture. While computers have had most of the glamour, photographic tech- nology in general, and particularly the advent of the quick-copying ma- chine, during the last seven years has so far had a more profound and widespread impact on library resources and services to readers than the entire field of computers and data processing. Within the next several years, computer and reprographic technology will be so closely inter- twined in libraries as to be inseparable. It would be a mistake to sell reprography short in the coming revolution. PROJECT SELECTION No academic library should embark on any type of automation program without first acquiring a basic knowledge of the projects and plans of the Library of Congress, the National Library of Medicine, the National Li- 88 Journal of Library Automation Vol. 1/ 1 March, 1968 · brary of Agriculture, and certain of their joint activities, such as the Na- tional Serials Data Program. As libraries with no previous experience with data processing systems move into the field of automation, they frequently select some relatively simple and productive projects to give experience to the systems staff and confidence in machine tec;hniques to the rest of the library staff. Pre- cise selection will depend on the local situation, but projects such as the production of lists of current journals (not serials check-in), lists of re- serve books, lists of subject headings, circulation, and even acquisitions ordering and accounting systems are considered to be the safest and the most productive type of initial projects. Since failures in the initial stage will have serious psychological effects on the library administration and entire staff, it is best to begin with modest projects. Until recently it was fashionable to tackle the problem of automating the serials check-in sys- tem as a first project on the grounds that this was one of the most impor- tant, troublesome, and repetitive library operations and was therefore the best area in which to begin computerization. Fortunately, a more realistic view of the serials problem has begun to prevail - that serial receipts is an extremely complex and irregular library operation and one which will probably require some on-line updating capabilities, and com- plex file organization and maintenance programs. In any case, it is de- cidedly not an area for beginners. A major objection to all of the projects mentioned is that they do not directly involve the catalo~, which is at the heart of library automation. Now that the MARC II tormat has been developed by the Library of Congress and is being widely accepted as the standardized bibliographi- cal and communications format, the most logical initial automation effort for many libraries will be to adapt to their own environments the input system for current cataloging which is now being developed by the Li- brary of Congress. The logic of beginning an integrated system with the development of an input sub-system for current cataloging has always been compelling for this author - far more compelling than beginning in the ordering process, as so many advocate. The catalog is the central record, and the conversion of this record into machinable form is the heart of the matter of library automation. It seems self-evident that sys- tems design should begin here with the basic bibliographical entry upon which the entire system is built. Having designed this central module, one can then tum to the acquisitions process and design this module around the central one. Circulation is a similar secondary problem. In other words, systems design should begin at the point where the perma- nent bibliographical record enters the system and not where the first tentative special-purpose record is created. Unfortunately, until the ad- vent of the standardized MARC II format, it was not feasible, except in Automated Systems in Academic Libraries/ DE GENNARO 89 an experimental way, for libraries to begin with the catalog record, sim- ply because the state of the art was not far enough advanced. The development and acceptance of the MARC II format in 1967 marks the end of one era in library automation and the beginning of another. In the pre-MARC II period every system was unique; all the programming and most of the systems work had to be done by a library's own staff. In the post-MARC II period we will begin to benefit from systems and programs that will be developed at the Library of Congress and elsewhere, because they will ~e designed around the standard format and for at least one standard computer. As a result of this, automation in libraries will be greatly accelerated and will become far more wide- spread in the next few years ( 7). An input system for current cataloging in the MARC II format will be among the first packages available. It will be followed shortly by pro- grams designed to sort and manipulate the data in various ways. A library will require a considerable amount of expertise on the part of its staff to adapt these procedures and programs to its own uses (we are not yet at the point of "plugging-in" systems), but the effort will be considerably reduced and the risks of going down blind alleys with homemade ap- proaches and systems will be nearly eliminated for those libraries that are willing to adopt this strategy. The development and operation of a local MARC II input system with an efficient alteration and addition capability will be a prerequisite for any library that expects to learn to make effective use of the magnetic tapes containing the Library of Congress's current c;atalog data in the MARC II format, which will be available as a regular subscription in July, 1968. In addition to providing the experience essential for dealing with the Library of Congress MARC data, a local input system will en- able the library to enter its own data both into the local systems and into the national systems which will l?egin to emerge in the near future. Since the design of the MARC II format is also hospitable to other kinds of library data, such as subject-headings lists and classification schedules, the experience gained with it in an input system will be transferable to other library automation projects. COSTS The price of doing original development work in the library automa- tion field comes extremely high- so high that in most cases such work cannot be undertaken without substantial assistance from outside sources. Even when grants are available, the institution has to contribute a con- siderable portion of the total cost of any development effort, and this cost is not a matter of money alone; it requires the commitment of the library's limited human resources. In the earlier days of library automa-:- tion attention was focused on the high cost of hardware, computer and 90 Journal of Library Automation Vol 1/ 1 March, 1Q.68 peripheral equipment. The cost of software, the systems work and pro- gramming, tended to be underestimated. Experience has shown, how- ever, that software costs are as high as hardware costs or even higher. The development of new systems, i.e., those without precedents, is the most costly kind of library automation, and most libraries will have to select carefully the areas in which to do their original work. For those libraries that are content to adopt existing systems, the costs of the sys- tems effort, while still high, are considerably less and the risks are also reduced. These costs, however, will probably have to be borne entirely by the institution, as it is unlikely that outside funding can be obtained for this type of work. The justification of computer-based library systems on the basis of the costs alone will continue to be difficult because machine systems not only replace manual systems but generally do more and different things, and it is extremely difficult to compare them with the old manual systems, which frequently did not adequately do the job they were supposed to do and for which operating costs often were unknown. Generally speak- ing, and in the short run at least, computer-based systems will not save money for an institution if all development and implementation costs are included. They will provide better and more dependable records and sys- tems, which are essential to enable libraries simply to cope with increased intake and workloads, but they will cost at least as much as the inade- quate and frequently unexpansible manual systems they replace. The picture may change in the long run, but even then it seems more reason- able to expect that automation, in addition to profoundly changing · the way in which the library budget is spent, will increase the total cost of providing library service. However, that service will be at a much higher level than the service bought by today's library budget. Certain jobs will be eliminated, but others will be created to provide ·new services and services in greater depth; as a library becomes increasingly successful and responsive, more and more will be demanded of it. CONCLUSION The purpose of this paper has been to stress the importance of good strategy, correct timing, and intelligent systems staff as the essential in- gredients for a successful automation program. It has also tried to make clear that no canned formulas for automating an academic library are waiting to be discovered and applied to any particular library. Each li- brary is going to have to decide for itseH which approach or strategy seems best suited to its own particular needs and situation. On the other hand, a good deal of experience with the development and administra- tion of library systems has been acquired over the last few years and some of it may very well be useful to those who are about to take the plunge for the first time. This paper was written with the intention of Automated Systems in Academic Libraries/ DE GENNARO 91 passing along, for what they are worth, one man's ideas, opinions, and impressions based on an imperfect knowledge of the state of the library automation art and a modest amount of first-hand experience in library systems development and administration. REFERENCES 1. Wasserman, Paul: Th e Librarian and the Machine (Detroit: Gale, 1965). A thoughtful and thorough review of the state of the art of library automation, with some discussion of the various approaches to automation. Essential reading for library administrators. 2. Cox, N. S. M.; Dews, J. D.; Dolby, J. L.: The Computer and the Libmry (Newcastle upon Tyne: University of Newcastle upon Tyne, 1966). American edition published by Archon Books, Hamden, Conn. Extremely clear, well-written and essential book for anyone with an interest in library automation. 3. Dix, William S.: Annual Report of the Librarian for the Year Ending June 30, 1966 (Princeton: Princeton University Library, 1966). One of the best policy statements on library automation; a comprehensive review of the subject in the Princeton context, with particular empha- sis on the "wait-for-developments" approach. 4. Fussier, Herman H.; Payne, Charles T.: Annual Report 1966/67 to the National Science Foundation from the University of Chicago Li- brary; Development of an integrated, Computer-Based, Bibliographi- cal Data System for a Large University Library (Chicago: University of Chicago Library, 1967 ). Appended to the report is a paper given May 1, 1967, at the Clinic on Library Application of Data Processing conducted by the Graduate School of Library Science, University of Illinois. Mr. Payne is the author, and the paper is entitled "An Inte- grated Computer-Based Bibliographic Data System for a large Uni- versity Library: Progress and Problems at the University of Chicago." 5. Kilgour, Frederick G.: "Comprehensive Modern Library Systems," in The Brasenose Conference on the Automation of Libraries, Proceed- ings. (London: Mansell, 1967), 46-56. An example of the evolutionary approach as employed at the Yale University Library. 6. Parker, Ralph H.: "Not a Shared System: an Account of a Computer Operation Designed Specifically and Solely for Library Use at the University of Missouri," Librm·y Journal, 92 (Nov. 1, 1967), 3967-3970. 7. Annual Review of Information Science and Technology (New York: lnterscience Publishers), 1 ( 1966) - . A useful tool for surveying the current state of the library automation art and for obtaining citations to current publications and reports is a chapter on automation in li- braries which appears in each volume.