As I track the trends in the library automation industry, I notice that the integrated library system, or ILS, isn't playing quite the prominent role it once did. Like an aging actor, it's been upstaged by a new generation of rising stars. Lately, the industry marketing marquees tend to give top billing to link resolvers, metasearch interfaces, and electronic resource management (ERM). While I believe that this new generation of automation products lends enormous benefits to librarians dealing with the new world of Web-based electronic content, it seems we have taken a step backward in terms of the integration and cohesiveness of our automation environment.
As the scope of libraries expands, we have an a la carte menu of automation utilities rather than a unified and comprehensive environment for library automation. This approach is a given, and it's probably a reasonable path. But, at times, it seems we might be better off today if the ILS had evolved in step with the times, changing the way that it packages information to better meet society's needs. But we-vendors and librarians alikeallowed the ILS to become static, and, by doing so, we diminished the possibility of having software that delivers more comprehensive automation for library workers and seamless access to information for library users. This error has resulted in libraries with tools that fall short of what is needed in today's world, where Google and Amazon.com set high expectations for Web-based, information-oriented interfaces.
Historical Roots of the ILS
The die of the ILS was cast in the 1970s, during an era when libraries dealt primarily with print materials. Without going into great historical detail, a broad observation is that the early automation systems aimed to provide an electronic version of the card catalog and to automate the functions of the library involving physical materials. Those systems came quite close to delivering comprehensive automation for libraries. They centered on print media, established the basic model for a computerized bibliographic system, and made great efforts at creating standards. During that era, the functional requirements for library automation and the business logic to meet these requirements began to take shape.
Times Have Changed: Though it probably didn't seem so at the time, the challenges of library automation of the '70s were less complex than those we face today. For the last decade, library collections have steadily grown to include nonprint content. Libraries of all kinds spend a major portion of their collection budgets on subscriptions to electronic content. Digitization projects are commonplace. Unfortunately, the core ILS did not evolve in step with these changes. At its heart, the ILS remains shackled to the antiquated printbased paradigm for library automation. Some minor concessions to electronic content emerged, such as static links through the 856 tag in the MARC record, but the fundamental nature of the ILS focuses on traditional content and work flow.
ILS Add-Ons: Though the development of the ILS itself has lagged behind, a bevy of other products has emerged to help librarians manage electronic resources.
OpenURL-based link resolvers provide an infrastructure for context-sensitive linking among the electronic resources to which libraries subscribe. Examples include SFX from Ex Libris, LinkFinderPlus from Endeavor Information Systems, MetaFind from Innovative Interfaces, and Sirsi Resolver from the Sirsi Corp. [Editor's Note: See the Helping You Buy installment on OpenURL Link Resolvers in the October 2004 issue of Computers in Libraries, pp. 17-24. Dynix has one now too.]
Metasearch products help libraries craft front-end interfaces for their electronic resources, allowing users to search multiple resources simultaneously. MetaLib from Ex Libris, ENCompass from Endeavor, Millennium Access Plus from Innovative, and Sirsi SingleSearch are some of the major offerings.
Electronic resource management applications assist the library in procuring and tracking details related to its electronic resource subscriptions. Innovative launched its ERM tool in 2002; in 2004, Ex Libris, Endeavor, and Dynix announced their ERM products.
Digital library products allow librarians to create, manage, and provide access to local digital collections. Product examples include Sirsi's Hyperion Digital Media Archive, ENCompass for Digital Collections from Endeavor, DigiTool from Ex Libris, Horizon Digital Library from Dynix, and MetaSource from Innovative. [Editor's Note: Make sure to check out the Helping You Buy installment on Electronic Resource Management coming in the November/December 2005 issue of CIL.]
In addition to these products, a library's Web site typically includes a set of static pages that provide details on its services, policies, and operational details. It might also contain database-driven pages for finding aids to e-journals, manuscript collections, and the like.
Not Enough Integration: It's clear that there is no one product that will solve all of the automation challenges that libraries face today. That's reality. A library needs an entire arsenal of software in order to manage and provide access to information in all its current shapes and forms. The problem with this lies in the lack of cohesiveness among this software armory. Rather than a set of tightly integrated modules, a library ends up with what feels like a federation of software applications that need to be marshaled into some semblance of order. The library finds itself integrating multiple diverse systems rather than implementing a single package. While this gives libraries more control and the ability to create a highly customized environment, it involves a lot of planning, design, and coordination.
On the back end, I see lots of opportunities for data and labor redundancy. In an environment assembled from several different component applications, a key challenge lies in avoiding the duplication of effort in maintaining data. When multiple modules of the ILS, the link resolver, the metasearch engine, and the ERM all deal with some aspect of data related to the library's electronic collections, for example, it's important to ensure that each of these tools work together efficiently. Library staff should not have to enter the same data in all of these different applications.
On the front end, it's enormously difficult to craft an environment for the library user that functions seamlessly. Can you imagine a searcher easily navigating through the library Web site, into and out of the Web OPAC, through a metasearch interface, and linking among a set of e-journals without giving up in frustration? The Google escape hatch awaits any user who finds a library interface too complex and frustrating.
Barriers to Integration: I see at least two culprits behind this associated, but not integrated, realm of library automation products-the library procurement process and the economics of the industry.
The nature of the requests for proposals (RFPs) that libraries use to evaluate automation systems, in my opinion, has had a large effect. In their RFPs, librarians tend to include long checklists of the functionality that they expect to see in their automation system. These checklists are widely shared among libraries, asking extremely specific questions about all the different modules of the system. The checklist tends to grow over time, rarely dropping any question pertaining to functionality.
On the positive side, the RFP checklist has helped vendors create a set of systems that have a high degree of functionality, adhere to established standards, and that generally can be regarded as mature. Vendors are highly motivated to provide positive responses to each item on an RFP checklist in order to stay in competition for new accounts in a competitive, though fragmented, market.
On the other hand, the RFP checklist may stifle innovation. Only the most adventuresome company would dare to offer a library automation system that makes a radical departure from the checklist-established norms, even if doing so resulted in an automation environment better suited to today's library environment. Overall, I believe the typical procurement process results in a more conservative approach to automation.
Business concerns may also contribute to the present ILS environment. If the technologies embodied by the current slate of add-ons were embedded into the core ILS, the cost of such a system would likely be more than the library market could tolerate. I think that, in many cases, the price of the ILS may be below fair market value. Therefore, companies have to make up the difference through the revenues they gain via add-on products, services, and content offerings. A truly integrated automation system with all of these capabilities as part of its inherent design might carry an unaffordable price tag. For example, although it might be technologically better to have OpenURL and context-sensitive link resolution as part of the native ILS capabilities, the cost of that technology would then become inherent in the cost of the system. Ditto with metasearch and ERM. The a Ia carte automation menu allows a lower automation entry cost for libraries with limited budgets.
Are There Any Solutions?
Whether through a single system or a collection of interrelated products, I think that libraries deserve a comprehensive, integrated automation environment. Does it exist already? If not, how do we go about creating it?
I think it's unlikely that a new system replete with all of my ideal capabilities will blossom. So far, the library automation industry has rewarded evolution more than revolution. Innovative's and Sirsi's systems have been around for more than 20 years; Horizon and Voyager more than 10. The demise of DRA's Taos system shows the risk of creating a new system from scratch.
I optimistically expect the current environment of the ILS plus add-ons tailored for electronic content to evolve into a more tightly woven environment. While the ILS may be mature, the supplemental products aren't and the linkages among them are even less so. On the technical front, the recent interest in Web services gives reason to believe that the evolution of an infrastructure to support better integration lies ahead. But, more than anything else, user expectations may drive us toward a more unified approach. We all live in fear of losing the attention of our clientele to the ever-popular nonlibrary interfaces such asAmazon.com and Google. I've heard this chorus at every library meeting I've attended in the last year. The stakes are high. Whether or not you agree with my premise that the automation environment lacks sufficient integration, the need to offer more cohesive and simple-to-understand interfaces to our users seems urgent.
