Washington University in St. Louis logo
Photo of redbud tree

Shirley Baker

Vice Chancellor for Scholarly Resources and Dean of Libraries

Managing Technology, Managing Technologists

When Dana Rooks asked me to speak at this conference, she told me I could talk on anything I wanted, as long as I mentioned libraries and technology. I've taken the liberty of reflecting on my thirty years experience with technology (and twenty-five with libraries) and woven together themes from those years. This talk is a compilation of advice, reflection, and lessons learned.

These are exciting times for technology and librarians. Technology has the attention of the entire world. Newsweek runs a special section on technology. The Chronicle on Higher Education has an information technology page that combines technology and library issues. University of California's Cliff Lynch, library technology guru for many of us, is quoted in Scientific American talking about Conan the Librarian, the super-powered creator of order on the Internet. People have become aware that librarians have been dealing with information technology for decades, using it successfully in reducing costs and improving services, engaging in successful collaborations, and creating order out of chaos. There may be more successful models than libraries in the business world, but I am not aware of them. Certainly, there are no more successful models in the world of education, of which libraries are a key part.

The emerging recognition of librarians' information technology skills is evidenced by the recent rash of appointments of librarians as chief information officers, of which tomorrow morning's speaker, Bill Crowe of Kansas, and I are examples. I should tell you, however, that, after some time in the job, we occasionally wonder whether there is not a parallel between librarians as CIO's and African-Americans as mayors of big cities - now that money is tight, the problems are great, and options are few, the jobs are open to us. But, that is for our cynical days. Most days, we have a better attitude.

Why are librarians being appointed to these positions? For starters, the administrators above us have become disillusioned with the purely technical leaders they've been relying on. Librarians are being made CIO's less for our technical skills than for our organizational skills and our ability to manage the complex change that is fostered by or linked to technological change. Also, because libraries serve the whole community, we tend to have a community-wide vision of what ought to happen and a strong service orientation. And, since we've never had enough money, we are used to working smart, and are learning to work even smarter.

The technological people we lead sometimes have trouble accepting being led by non-engineers or non-computer scientists. There are days when I consider peppering my conversations with jargon (a habit I spent years breaking) just to increase the comfort level of my technology staff. However, a few small victories help gain confidence. Technology suppliers in our institutions are pretty embattled, and anything that can begin to make them look better is welcome.

There are a series of questions I will pose and try to answer throughout this talk. The questions are:

The technology has brought us inventory control, communication, and collaboration. I'll talk about each of these in some detail in turn.

Inventory Control: The first library computer systems were modifications of industrial inventory control, which, for a library is circulation. When I worked at AT&T, we had two massive and identical computer facilities, one three floors underground at a safe distance from New York City, which ran in parallel twenty-four hours a day, to maintain the inventory of long distance phone circuits. In the mid-1970's at Hopkins, our CLSI system was designed for inventory control, and it was only after creating brief records for four years that we expanded our thinking to include an online catalog (and, of course, had to start over). The early circulation systems missed some of the nuances of library inventory control. It turned out that the architecture of the early CLSI system did not allow for charge on charge, i.e. charging out a book to the reserve room and then recharging it to patrons. That's why, even though we had contracted for that capability, we got it seven years after contract signing.

Communication: Information technology has brought us communication, both communication about resources and communication person to person.

Initially, we communicated to our patrons, only within our physical facilities, about some of the materials we owned and whether they were checked out. When we began to think about online catalogs, we could not envision ever doing the retrospective work to get pre-machine readable records into machine readable form. The task, when we compared it to the effort for cataloging new items, was beyond our ability to pay, especially if we were to take advantage of the opportunity to improve the old catalog records. Remember, this was the 1970's, when we were at the height of our commitment to the perfect, complete catalog record, when our professional conversation was dominated by talk of AACRII and authority control. We had conveniently forgotten that libraries such as the Bodleian had managed to support scholarship for four hundred years with the briefest of records, single entries pasted in book catalogs, in sort of alphabetical order.

When I worked at Northwestern, NOTIS, which had been developed there, was only a few years old, still nameless, and not yet marketed to other institutions. It had been designed by the brilliant physicist Jim Aagard ( a pale remote presence in the library staff lounge) and the equally bright but more socially adept Velma Veneziano. It had acquisitions, cataloging, and circulation functions, and was based on full MARC records. I vividly remember Velma Veneziano asserting that one day the card catalog would be removed and be replaced by terminals. Many of us didn't quite believe her. But, of course, she was right, and NOTIS, with its MARC-based design and economic code, became a commercial product, one with an exceptionally long shelf life.

Of course, our early online catalogs communicated only a portion of the contents of our libraries. Not only did they not have our earlier acquisitions; they often did not have government documents, maps, microforms, or the contents of our journal subscriptions. I estimated that, in the 1980's, the typical online catalog represented 5% of what was in the library. We've increased that percentage dramatically, first through retrospective conversion of our card catalogs and then through adding other materials, including indexes to articles in journals.

I've come to believe that doing retrospective conversion was the most salutary experience for librarians in the last thirty years. By using bibliographic utilities such as OCLC, we had moved partially away from our belief in the uniqueness of each of our libraries. However, retrocon solidified that move. The experience of having to define an affordable standard for converting old records gave our technical services staff the finest experience with cost benefit analysis and brought a breath of reality to what had been a cloistered world.

That experience served us well when we moved on to adding journal indexes and other databases to our online catalogs. Arguing that it was OK to put a record in the catalog for an item you did not own (but could acquire on demand) was an easier discussion, once we had broken the image of our catalog as a perfect and sacrosanct reflection of our library. Early card catalogs often had journal analytics in them, records for each article in the periodicals to which the library subscribed. The increase in the number of periodicals quickly snuffed out this local activity; libraries left the analytic business to publishers of indexes and abstracts; and most libraries pulled the existing analytics from their catalogs. Cal Tech was the first to experiment with bringing the analytics back into the now online catalog, an experiment which failed the first time around but went on to success. Now we discuss whether the indexes should be loaded locally or accessed remotely, how much full-text we can link to, and how we will pay for it. And, we add tables of contents for books to the searchable catalog record. User heaven!

Dial-in access to our catalogs: How many ports would we need to assign to dial access? Was it encouraging user irresponsibility to allow them to check the catalog without coming to the library? These were questions we discussed in the late 1970's and early 1980's. Four ports was usually the answer to the how many ports question. Does better service corrupt our users is a question that continues to pop up in discussions of changes in libraries.

More on communication: When I got my first email account in 1980, I was in hog heaven. I was the RLG coordinator at Hopkins, an east coast university, and required to communicate with RLG on the west coast, in a different time zone. Having email freed me from the annoying problem of having to figure out whether the RLG staff were out of bed yet. It was some time before electronic mail became available to all staff; we'd gotten it at MIT in about 1987. Of course, I then left MIT and had to re-institute email at my new institution and acclimate a new staff to its use. I do feel that a pattern in my career has been repeatedly going backward in the stream of technological evolution. Certainly, in taking over information technology at our university, I must solve, once more, several problems I've already solved in libraries.

An unresolved question in remote access to information resources remains, "How do we limit use of some resources to our authorized user community?" Given the primitive state of authorization systems (indeed, in many institutions we don't have a single, compete file of authorized users), that one will take some time to resolve. At Washington University, where I insist we not write code for anything that we can buy from a vendor, we continue to write the code for authorization, scripting, and passwording, so that our legitimate users can easily access the expensive resources that we have purchased for them.

Collaboration: The third answer to "What has the technology done for us?" is foster collaboration. We had been collaborating in the pre-computer days. Many research libraries sent their holdings information and their cataloging copy to the Library of Congress, to be published in the National Union Catalogue, so that scholars could find locations of research material. But the development of the MARC record, the availability of LC records on magnetic tape for loading on local systems, and the ingenuity of Fred Kilgour and his Ohio compatriots in inventing OCLC for card production has been our greatest collaboration. That collaboration has not been without bumpy moments. We owe the existence of RLG, I think, to OCLC's not taking seriously enough major research libraries' contributions to OCLC. Then again, we've owed the enhancement of many OCLC services to RLG's willingness to offer them. Sorting holdings for a title by geographic region was one I remember. OCLC insisted this couldn't be done. RLG did it. Two months later, OCLC's holdings sorted by region. Love that competition!

No one expected, when the bibliographic utilities were born, that they would emerge as giant resource sharing facilitators. The availability of holdings as a location mechanism quickly drove the National Union Catalogue out of mainstream workflow for interlibrary loan departments. I came into interlibrary loan just as the utilities were introducing their ILL messaging systems. I remember being trained by the retiring interlibrary loan librarian about the intricacies of the paper union catalogs, but then using them almost never, thereafter. Mansell, the publishing project that merged all the pre-1954 National Union Catalogue series into one alphabet, was at the M volume when it was blind-sided by OCLC. I think most libraries maintained their standing order for the subsequent volumes, but use of the compilation has been almost non-existent since the early 1980's.

After bibliographic utilities and interlibrary loan, other collaborations have been facilitated by the technology, and by librarians' willingness to look continually for ways to work together for the common good. Reciprocal borrowing among libraries using a shared system was pioneered in Illinois, under the radical leadership of Hugh Atkinson at the University of Illinois, Urbana-Champagne. Atkinson proved to us that the largest libraries can be winners in an organization that opens the holdings of all sizes of libraries to each other, a truly counter-intuitive idea. The full flush of Atkinson's pioneering work came only in the last decade, when academic institutions in the state of Ohio had their reservations about loss of institutional autonomy bought out by state money for the OhioLink system. Now, other regions are rushing to jump on this bandwagon.

A final area where information technology has fostered collaboration is in electronic publishing. We have been waiting a long time (and often with warranted skepticism) for electronic publishing to alleviate the budget and space problems we face in libraries. Our parent institutions, of course, think that the millennium is here and we'll all wake up tomorrow morning to discover our books gone from our shelves and our buildings no longer necessary.

I've said that electronic publishing will become real when publishers have figured out how to make money doing it. Until then, we are stuck in a paper world. And, we've all argued that it would be a cold day in hell when we began retrospectively to digitize volumes and remove them from our shelves. Everyone knows of digitizing projects which were nothing more than vanity publications, had little use, and became albatrosses as the technology to read the digitized text changed. However, when Brian Hawkins of Brown said, in the early 1990's, that we should begin the digitizing of our retrospective collections, I tempered by knee-jerk, No Way!" with the memory of my similar reaction to Velma Veneziano's statement about digitizing our card catalogs and how wrong I had been to disbelieve her.

In a period of about six weeks in the fall of 1995, I had two experiences which made me re-evaluate my skepticism about digitizing our collections. The first was hearing OCLC describe their renewed plans to support electronic publishing AND archiving, at a cost we could imagine affording. Then, within a short period of time, I heard about the economics of the JSTOR project, that is was possible to digitize, archive, and access core journals in our collections, provided we shared the costs. Head spinning, I began to try to imagine my library with no paper current journals and no bounds journals (or, to be realistic, only esoteric paper journals, to narrow to reap the benefits of cost-sharing). What if our shelves did not have long runs of identically buckram-bound journals? What if they only had single volumes, the kind that almost leap off the shelves, asking to be read?

But why am I talking about digitization under the rubric of collaboration? Because the means for digitization come out of collaboration. OCLC is a membership organization, a creation of librarians, doing for us what we cannot do individually. And, collaboration between librarians and the Mellon Foundation is well-established. There are topics about which only libraries and the Mellon Foundation care. Preservation of endangered books is one of those topics, and the Mellon Foundation played a critical role in helping libraries address that issue. Digitization of core humanities and social sciences journals appears to be another. No one is going to make any money digitizing these titles. And yet, scholarship will be enhanced by opening up dead volumes to new scrutiny and libraries will be able, guilt-free, to clear their shelves while enhancing scholarly access. Technology makes this collaboration possible.

What has been needed to make the technology work for us?

The answer to this is a short sermon on the virtues of librarians!

First and foremost, I would say, signs of intelligent life, by which I mean general intelligence and willingness to learn. I talk about signs of intelligent life when I guide search committees who are hiring staff. Having chaired more than thirty search committees in my life, I've come to weigh academic degrees and specific experience no greater than signs of intelligent life. Our work lives change so quickly these days that what we know often has little bearing on what we have to do next. Thus, librarians being generally well-supplied with signs of intelligent life, we've done quite well in making the technology work for us.

Our openness to change and improvement have also served us well. Sometimes it may be hard for us to break out of comfortable molds, but we can do it, and after the first such break-outs, future ones are faster and less painful.

Our commitment to creating and using standards has helped us make collaborative use of technology possible. We have created standards such as the MARC record, Z39.50, and ISO 10160 and 10161, and we require our vendors to use these standards.

Finally, we have been well served by our increasing willingness to give up local control in trade for dramatic expansion of possibilities, has allowed us to make leaps unthinkable a decade ago. We may be frightened and apprehensive as we take these leaps, but we are taking them.

How effectively are we managing the technology?

We are more effective at managing the technology than we've ever been, but we have struggled with leadership. We've had leaders who were afraid of the technology and who would avoid it if at all possible; if they could not avoid having the technology in their organizations, they gave free rein to the technologists to do as they wished. We've also had leaders who were infatuated with the technology, who obsessed on it to the detriment of their other legitimate work, and were the prime markets for vaporware. I used to think that I would go to the old librarians home, or even be buried in the old librarians' graveyard, before I worked for someone who was neither of those, someone who wasn't dazzled by the technology, but could ask the right questions. But, we are seeing the first of that breed, however, and some of us think that we are in that category.

In our early efforts of managing the technology, we struggled to describe the complexity of our operations so that system designers could create systems rich and flexible enough for us. Our failures in communicating complexity to designers gave us those early systems that couldn't handle reserve room functions or which only used the briefest of records.

We also went through a period when every organization with any pretensions was designing its own system and marketing it to colleagues. Needless to say, many of these systems disappeared from sight. Libraries became more savvy about writing software locally; they learned one of the key insights in information technology: Vendor-supplied software keeps up with technology changes better than locally written systems. The locally-written software does get many small modifications. However, it tends not to make the big, technical leaps required to stay abreast of technology changes. Vendors have to be rewriting their product constantly, to sell it to new customers, who are comparing the hardware and software to the current market. Local systems somehow cannot make those big leaps, and drift further into backwaters, until replacing them is a wrenching experience. Librarians have mostly learned to buy rather than write, whenever possible. Some other information technology users, especially in higher education, haven't figured this out yet, and it is a challenge for those of us trying to make improvements in non-library areas.

In the mid-1970's, there was a sorting out in the market between relatively simple, turnkey systems, which could be used in a library with little technical expertise, and complex systems which required considerable on-site programming. To deal with these turnkey systems, we had to figure out how much technical expertise was really required, and I cut my teeth on turnkey systems working at Hopkins picking up the pieces from an early installation. In the process, we learned an important lesson about implementation - how easy it is to bring up an automated system AND keep paper records for the same functions. We also learned to be aggressive and relentless in dealing with vendors. We learned about industry standards for up-time and the normal rate of equipment DOA (dead on arrival). Many of us learned how uncooperative vendors could be, especially after you've paid for your system. The best time with any new system is after you have signed the contract and before you have paid. In that period, you get the attention you need. After that, it is hit or miss, and often miss.

First we struggled with too much simplicity; then we struggled with too much complexity.

As Hopkins planned for the replacement for its system, going beyond plain circulation to an online catalog, we learned about how much we could ask vendors to do for us. In those days, the specifications for a system were handled mainly by the catalog department. The arrival of automation in cataloging (primarily OCLC) had been recent enough that catalogers were just getting a taste of what the technology could do for them. Thus, in writing specifications for local automated systems, they were ready to outline, as essential for purchase, every feature they could ever imagine having. This was, of course, long before cost pressures caused us to eliminate many of the nuances of cataloging and before catalog departments were threatened with outsourcing. Thus, we developed dream requests for systems which were far too complex to run on the cheaper mini-computers. A few hapless vendors took us at our word and signed contracts with us to develop such dream systems. Most of these vendors went out of business before they could completely bring up their systems. Prestigious universities were particularly vulnerable to designing dream systems.

Aside: One of the key goals of the North American Interlibrary Loan/Document Delivery Project is to delineate for the vendor community what features the library community must have in the software developed for ILL/DD. This means constant wrestling within the library community over what are bells and whistles and what are essentials. This is not an easy task, but an essential one if we want to get workable software at an affordable price any time soon.

In managing information technology over time, we've vacillated between control/lack of control and between centralization and decentralization. These are issues that go beyond libraries and it is probably worth a digression to talk about what was happening in computing in universities during this period. When I arrived on the scene (or became aware of what was going on) in the 1970's, the tension between the mainframe guys and the mini-computer people was in full bloom. When there were only mainframes to deal with, computing power was held centrally, and those who wanted to use the computers, whether to run the university's payroll, to keep track of registered students, or to do research, were at the mercy of the computer gurus, who, like any despots, abused their power over time. Because of the esoteric nature of what they did, they called the shots. When they wanted new toys (upgrades or new machines), no one could question their logic (administrators didn't know enough and the technologists made it clear that only other technologists could judge their work.) Thus, in the worst kind of generalization and over-simplification, they ran what they wanted when they wanted, on whatever machines they fancied, for which they passed on the charges to their hapless users.

Needless to say, it was only a matter of time (and technological innovation) before their hapless users rebelled. The invention of VAX-type computers by Digital Equipment and other upstart rivals of IBM, freed researchers from bondage to central computing. For $100,000 (rather than a million or more), one could buy quite a powerful machine, affordable on a grant and programmable by ingenious faculty and graduate students. These machines did not require the specially constructed machine rooms and disks now came in removable packs, the size of a Chicago-style pizza, rather than in refrigerator-sized, untouchable modules.

The available-to-the-masses machines led to the VAXination of the university. Research computing (at least for the scientists) escaped the clutches of the central, mainframe-based organizations. However, most social scientists and humanists remained in unhappy thrall to central computing organizations until the advent of the personal computer. The ramifications of this thrall remain with us today, as we try to solve problems with use of technology within our universities; memories are long.

There were side effects for libraries when central computing organizations lost big chunks of their business. Since the library system was one of the few large enough to justify a mainframe, central computing staff began to demand that the library have a system that would run on hardware that they could use for other applications. If they couldn't capture the library system, they would lose all their income for buying new toys. We lived through this adventure in the mid-1980's. Systems which ran on proprietary hardware, which was of no interest to our central computing friends, had some hard times, until they could be re-written for standard hardware. And, many libraries found themselves having their system choices made for them by central computing staff.

The arrival of personal computers in large numbers, and ultimately of networked personal computers, has complicated our lives even more. We went from mainframes to VAX's to PC's to networked PC's. Another way of putting it is that we went from control to freedom to anarchy and are just now beginning to reach controlled freedom. We have hopes to return to some sort of control, if the promise of NC's (networked computers) is fulfilled.

In the mainframe and VAX world, we didn't know how good we had it. While we thought we did support pretty badly, we didn't know what bad support was. Having an organization with dozens or hundreds of personal computers, all configured differently, each running the software chosen by the user, each requiring support, is insanity. Now that we are able to network personal computers, we can keep key software on servers and make updates universally. NC's, having almost no locally mounted software, may be wonderful. But, I have learned not to put too much stock in promises about technology. . . . .

What have I learned in all this?

I've learned that doing technology in the world's best-known institute of technology has particular challenges. MIT is where technology is invented. At MIT it was easy to get support for technology experiments but difficult to use technology for everyday operations. Using technology, not as an experiment, but as a support for reliable service means using technology that is no longer at the bleeding edge. It took chutzpah to implement the only systems that would work reliably - those written in "old" languages and running on "old" machines. It also took some chutzpah to avoid having a few bright students write your software for you. The first question I had to answer was, "Why did you buy software when we have the talent at MIT to write us far better than we could buy?". By this time, I had enough experience with the fleeting interest of volunteer system developers and their notable absence when it came to fixing bugs and adding new features to give a convincing answer to the question.

I've also learned to question everything and everyone! As someone who came up through public services, I thought that we knew our users. However, when the public services staff wrote the first user handout for the online catalog, I had an awakening. Two pages of fine print on what was not in the catalog and how you could not search it (no Boolean, no truncation, no limiting) came before the announcement of what you could do (find any of the million items that had been cataloged since 1968). The careful training that these librarians had in searching Dialog had made them think that was the only way to search. Accepting that our users often want something, not everything, and not even the best thing on the topic does not come easily to reference librarians. While Jane Burke would tell them that data shows that 90% of the users do single term key word searches, they didn't believe her. While OCLC's First Search was sweeping the nation, reference librarians insisted that the system was useless. It didn't provide the or command; one was not able to specify this or that,. OCLC finally gave in and programmed in the or function; it accounts for six-tenths of one percent of all searches.

What else have I learned? Mid-level staff become hooked on the processes they've designed to keep themselves out of trouble, processes that double-check for errors they once got yelled at for making, or processes which solve problems that no longer occur. Changing these processes requires peeling staff fingers off of them. Bringing in new systems that work in other environments may be one way of peeling staff fingers off these processes. The best way, however, is to do process redesign beforehand, working with tough outsiders who question everything and who make sure that the real end-users needs are kept paramount. Work is just beginning to be done on what the actual end-users (faculty, students, and the public) hope to get out of oursystems. Most of the staff who use the systems in their work think the systems are designed for them, rather than for the user community. The notion of process redesign as we write specifications is still not universally accepted.

I have also learned the negative power of institutional autonomy. While half a dozen institutions within ten miles of each other were installing systems, we never even thought about getting the same system and sharing it, or linking our systems. Institutional autonomy played too strong a role. We were too different to use the same system, or, if we actually got the same system, to implement it the same way. We've made great strides in suppressing the institutional autonomy urge, when it serves our users to do so, but we still have a long way to go.

I've learned that new technologies can be exciting in bad ways; they cause people to go around looking for problems to solve. Give a child a hammer, and suddenly everything needs hammering. Provide a new technology, and suddenly we need it! What did we think client/server would do for us, when we all started talking about needing to move in that direction? Big organizations with lots of money invested in client/server early, and found themselves fondly remembering their mainframes. Why did it not occur to us how hard it would be to maintain clients on the ten thousand disparate machines at our universities? "Saved by the Web," is my comment on client/server. How lucky we were that a common, freely available client (supplied, loaded, and maintained by someone else) came along to save us! Indeed, the availability of the Web as a user interface allows us to keep our mainframes running while we look for something better. People cannot tell that your flashy Web interface covers a very old-fashioned system.

But, the most important thing I've learned is that managing technology is mostly about managing technologists. Left to their own devices, technologists will do what is intellectually interesting. Intellectually interesting does not describe most of what you will need to have done. Thus, your job, as manager of technologists is to get them to do what they don't want to, and to keep them relatively happy while they are doing it. This requires self-confidence on your part, confidence that you really know what needs to be done. Input from end users is powerful here. You should expect to have to bribe your technologists and to bully them: give them enough new toys so that they don't get bored, but also keep after them to do those things that are absolutely necessary but not exciting. . . . .like solving problems they already know how to solve, so are not interested in actually doing it, or keeping the printers running, or keeping all parts of the network up, etc.

At Washington University, we are implementing a new system. It is not a technically exciting system, but it serves a key purpose for us - provides for cost effective resource sharing in our consortium. And, of course, it does all the other things that library systems do. The selection of the system was as much a political as a technical issue. None of my technical people are very happy with the decision. The chief programmer, who is abandoning fifteen years of experience with NOTIS and his entire informal support network, plugs away grumpily at database conversion. Our head of systems, who wanted something cutting edge, grits his teeth and installs software that he doesn't much care for. My leadership role is to allow them to grumble and complain, but to make them do the right things nonetheless.

I said that I would end with some remarks on the challenges we face. Much of what I've talked about is looking back, but trying to draw out lessons that still apply. What are our current and future challenges?

The first challenge is convincing people that print still matters. The idea that print is dead has been around for twenty years, and it is still not true. Being able to talk about what print remains good for, as well as what electronics can do, is essential. But, it is a battle we must fight again and again.

The second challenge, for libraries, is keeping our buildings and keeping them up. Our buildings don't just house books; they serve as places that people come when they want to be serious. There will always be a demand for spaces for quite contemplation. Increasingly, our libraries serve as places where people collaborate, combining technology, print and human spirit. Our libraries will probably look quite different, but they will continue to be important as edifices.

The second challenge applies also to institutions of higher education in general. If we believe the Peter Druckers of the world, there will be no universities in the next millennium. I think he is wrong. Some universities will disappear, but others will remain. Some of the placeness of the university is worth retaining.

The third challenge involves the use of technology in teaching and learning. There is the temptation here to use the technology as a child would use her new hammer - everywhere. However, if we are to use our resources wisely, we should be asking, "What problems do we have that the technology can solve?" I've seen some wonderful work with solving problems for introductory chemistry. I've also seen a lot of "hammering".

The fourth challenge is to separate the technical problems in distance education from the legal, political, and social problems, in the minds of our leaders. As usual, the technology is the least of the problems, but our leaders seem to see it as the total solution. The legal, political, and social issues will be far more difficult to resolve than the technical issues.

A fifth challenge, and this may be wishful thinking, is to slow the pace of change. Keeping up with Bill Gates has become something of a nightmare for even the nimblest of technical planners. I understand, however, that some very large industries have delayed using Gates' latest release. Several captains of industry have reputedly taken Bill Gates aside and told him he should make his releases less frequent and more meaningful if he wants their business.

The final challenge, of course, is money. It has always been a challenge to find funding for technology, even with institutional predilections to fund technology over other needs. But, with the increasing dependence on technology, the pace of change, and the very real need to train and support, dollar needs are greater than ever. Within my libraries, we have a solution. We have an endowment for library technology, and it is sufficient to fund hardware and software replacement. We must still address the human resources issue, but not having to scrounge for money for equipment is a treat in this job. I can only fantasize about how much easier my vice chancellor for information technology job would be with similar support. I argue that our parent institutions should find the money to endow technology university-wide. This is the perfect practical and symbolic act for the 21st century institution.

In my introduction, Dana referred to my children's talking about Mom and the age of dinosaurs. My son elaborated on that comment. He said he was talking about computers the size of dinosaurs. At the contract signing party for my library's new system (where we consumed a case of champagne) we had the hardware for the new system on display. Our server is the size of a portable typewriter, it cost half of what I used to spend for a disk drive, and is more powerful than the entire room of computers I used to work with at AT&T. Those dinosaur computers I worked on so long ago are now in the Computer Museum in Boston, relics of the past.

Shirley Baker is Vice Chancellor for Information Technology and Dean of University Libraries at Washington University in St. Louis. She grew up in rural Pennsylvania and has been running away to the city ever since. She was educated at Muhlenberg College in Pennsylvania and the University of Chicago. Shirley entered the grown-up work world in data processing at AT&T, served as a Peace Corps volunteer in India, and then became a librarian. She thought she was going to be an area studies bibliographer.

She has worked as a librarian, mostly in technology and management positions, at Northwestern University, Johns Hopkins, MIT, and Washington University in St. Louis. She has been working with computers since 1965, or, as her children say, "Since Mom was young and dinosaurs roamed the earth." She remembers when computers with only 4000 bytes (4K) of memory were as big as Volkswagens and when computer rooms were the size of football fields. Shirley has worked with home-grown systems, with NOTIS, CLSI, GEAC, NOTIS again, and now Innovative Interfaces. She has experience with both OCLC and RLG.

She accidentally got involved with interlibrary loan (negotiating a better deal in a staff reorganization) and has made something of a career of working to lower the cost and increase the effectiveness of resource sharing. She leads the Association of Research Libraries' North American Interlibrary Loan/Document Delivery Project, to improve technological support and change work practices. She is the outgoing chair of OCLC's Research Libraries Advisory Committee, serves on the board of the Association of Research Libraries and the Missouri Research Library Consortium, and chairs the Board of the Missouri Library Network Corporation.

Shirley K. Baker
Vice Chancellor for Scholarly Resources
    and Dean of Libraries
E-mail: shirley.baker@wustl.edu
Washington University
Campus Box 1061
St. Louis, MO 63130
Phone: 314-935-5400
Fax: 314-935-4045