The major trend in library automation over the last 5 years is a rapid increase of applications that are designed to help us deal with collections of expanding digital content. Before that, integrated library systems helped us automate practically all aspects of collection management. It was all so simple back when our collections consisted almost exclusively of printed material. We dealt with books and serials that were mostly printed on paper, with some on microfilm. But they were all physical items you could touch.
Prior to computers, collection management involved a lot of manual, repetitive work. Catalog cards were handwritten or typed and manually filed according to main entries and tracings. Various card systems were invented to help us circulate books. My career at the Vanderbilt University libraries began at the tail end of this manual-processing era. Computer automation brought radical improvements to the library's internal operations and made it far easier for users to locate materials. The early automation systems were monolithic, centralized operations that were based on mainframe computing.
The ILS was initially designed to computerize all the manual tasks associated with managing libraries that had large print collections. The acquisitions module helped us buy and pay for books, while the cataloging module adopted the rules for producing catalog cards and applied them to creating an electronic bibliographic database. The circulation module automated the business rules of the circulation desk. The serials-control module managed the check-in, routing, and processing of serials and periodicals. The OPAC served as an electronic card catalog that leveraged the databases and indexes created by the other modules so users could search for and locate materials.
Although modular, these earlier automation systems were monolithic. Each of the modules relied on access to a central set of databases for their functionality. A bibliographic database described each title held by the library, while an item file represented the individual copies. Asingle patron database represented all users, and the vendor file kept details of all the companies from which the library purchased materials. It was a tidy world where all of our collections could be represented by a small number of large databases. Although automation seemed complex at the time, the data models were simple. One database held each category of information. Yet these systems offered a comprehensive approach to library automation.
Today = Print + Digital
Then came the digital revolution. Beginning about a decade ago, libraries became deeply involved in acquiring electronic content in addition to their traditional print collections. At first, the amount of digital content was fairly limited, maybe a few dozen e-journals. Librarians kept lists of them on Web pages for users. But dozens soon became hundreds, and hundreds soon became thousands.
For many libraries today, investments for digital content outpace those for print materials. Acquisition comes in many forms. Some content is acquired individually, but much is obtained through big aggregated collections. The information products that aggregate large numbers of e-journals are notoriously unstable. E-journal titles come and go, depending on ever-changing business relationships with publishers and scholarly societies. Access to these collections is governed by contracts and licenses with complex and varying terms. All the electronic content purveyors have different expectations regarding access, pricing, and service.
Today's users expect us to provide- to the largest extent possible-access to the full text of articles. Libraries subscribe to products that include not only just the citations but also the full text of scholarly journals, periodicals, and newspapers. Users highly value these full-text resources and expect easy access to them. Librarians struggle to attract their users to the high-quality, reliable, scholarly information they provide rather than have them rely on the informal, less authoritative information so conveniently available on the Web.
Keeping track of collections with both physical and electronic content is an incredible challenge. Today's library automation requirements are far more complex than those of previous times.
Applications Proliferate
Today's libraries need to manage both print and digital resources. Even though the volume of electronic content increases at a steep rate, I fully expect that the need to manage print collections will continue into the foreseeable future. This age of both print and digital content has brought a plethora of systems to libraries.
A typical academic library needs a whole arsenal of products, including the following:
- An ILS for managing the library's physical collections
- OpenURL link resolver to provide linking and other access options for electronic content
- A federated searching tool to make it easier for users to search multiple information resources simultaneously
- An electronic resource management (ERM) system to help staff manage subscriptions to electronic content products
- An institutional repository for archiving and accessing scholarly articles or other material produced within the organization
- application for creating and managing local digital content, such as photograph collections, digitized manuscripts, or other special digital collections
The days of a single, monolithic automation system are coming to an end. Instead, many libraries must work with multiple systems. Although each application deals with its specialized niche in the overall scheme, the applications are interdependent and often involve overlapping content. In broad terms, some of the data models might include the following:
- The ILS's bibliographic database, which describes the library's collections of books and serials. The ILS will also include an item or holdings database that specifies the number of copies of each title and provides location and shelf status. While the ILS describes the collection of print and electronic journals, it doesn't offer access to the individual articles within them.
- The OpenURL link resolver. This model relies on a database of e-journals that's derived from a profile of the library's subscriptions. Many libraries use the knowledgebase associated with their link resolver to update electronic journal holdings in their ILS. As libraries invest in large collections of fulltext content, link resolvers provide an important part of the infrastructure to connect users to these resources.
- The ERM, which is derived from a database of the library's electronic subscriptions. This database overlaps with the link server knowledgebase. The ERM maintains a file of the vendors from which the library purchases electronic subscriptions. This may duplicate the ILS's vendor file.
- Alternative front ends to information sources. These include Endeca Guided Navigation, AquaBrowser Library, Primo, and Encore. These interfaces depend on wholesale harvesting of bibliographic data from the ILS, link resolver, and other sources.
Working in an Age of Loosely Coupled Systems
While the specifics vary from one library to another, these systems and their associated databases serve as an example of the intricacy of managing and providing access to complex collections with both physical and digital components.
In contrast to the earlier, more monolithic approach, the various applications in the modern library environment operate in a loosely coupled, often nonintegrated way. The functionality involved in managing electronic resources has been addressed by the development of separate products rather than as evolutionary extensions to the existing ILS architecture. This isn't surprising to me since the ILS was initially conceived to automate print collections and just didn't have the underpinnings to accommodate the vastly more complex task of providing access to the extremely large bodies of digital content.
The Art of Integration
Libraries that are heavily invested in delivering both print and electronic content will need automation products beyond the core ILS to meet their users' needs. Given this reality, there are two key goals to keep in mind as you acquire and implement the components of your information environment.
First and foremost, the library's environment must be seamless and simple for patrons to navigate. No matter how complex the system is behind the scenes, you must aim for a simple, coherent user interface. It's relatively easy to put up several different systems and make users navigate through them as separate entities. It's more difficult to integrate them in such a way that users are completely unaware of the constituent components.
A secondary but essential goal is to efficiently implement the components of the library's infrastructure so you can mitigate the level of effort needed to sustain them. It's important to avoid redundant work and counterproductive work flows.
Given the reality of multiple, nonintegrated, loosely coupled systems, how can libraries operate all of the components they need most efficiently? Achieving integration that works both to gain a unified user interface and optimized work flow behind the scenes will involve artistic creativity and the practical application of technology.
Waiting on Web Services
In today's environment, the key technology for interoperability lies in Web services. As a system-to-system protocol based on XML, Web services are well-suited for applications that offer their own discrete services but also rely on external resources for part of their functionality. Web services would be the ideal approach for integrating the various applications used within the library environment.
While the library automation sphere has increasingly adopted Web services in the last few years, they're far from ubiquitous. In the current environment, you can't count on this protocol as the primary way to integrate applications. Web services remain something we can look to in the future if the developers of automation products can make better progress on defining and implementing them in a way that addresses the current gap in interoperability among applications. To the extent that Web services are available, they're the preferred approach for achieving front-end consistency and back-end interoperability among diverse applications.
Practical Practices
In the absence of a full Web-servicesbased model for interoperability, we can employ a number of pragmatic strategies to operate a suite of diverse library automation applications efficiently.
We can use many techniques to present a more coherent user interface. The library's Web-based environment should have a consistent look and feel, regardless of the application that generates any given page. The color scheme, graphics, and page design should be uniform throughout. We can accomplish this by customizing the applications to generate HTML code as consistently as they can. It should be possible, for example, for each of the applications to rely on shared HTML code snippets- which are usually implemented through server-side includes-to generate the headers and footers on each page. At the very least, all applications should use cascading style sheets and each should use the same style sheet.
The ideal library environment should also operate within a single authentication framework from the user's perspective. Once the user signs in to gain access to a given feature, it should not be necessary to sign in again with the same session, even if the services are delivered by different back-end applications. Not only is it important to offer a persistent sign-on as users traverse the applications, it's also desirable to take advantage of any sign-on that users may have already performed. For example, if a student signs on to his or her courseware account, it shouldn't be necessary to sign on again to access the library's content and services. However, singlesign- on technology can be extremely difficult to accomplish.
There are also a few strategies that can help ensure an efficient environment behind the scenes. The main considerations are to do a thorough analysis of the data work flows that are involved and to select components that require the least intervention by library staff.
We must give the utmost attention to data flow. In designing the library's automation environment, it's essential to manage the data efficiently. There should be a single point of management for each data category. It's not acceptable to manually edit and update the same data on multiple systems. While we expect multiple applications to share data, it should be done in such a way that changes can be made on a single system and automatically propagated to the others.
Many of the products that deliver access to electronic content are fundamentally data-driven. Especially for link resolvers, the quality of the e-journal database is the most important consideration. The accuracy of that data and the efficiency in which it flows to the ILS, the ERM, and other back-end systems will make the largest impact on the amount of work the librarian must do to maintain the environment.
When selecting applications, we should do so in a way that mitigates the number of vendors. It's not uncommon for libraries to acquire software and services from multiple companies. The relationship between a library and a vendor takes significant resources to develop and support. It's important for the vendor to have a good understanding of the library's individual strategies, policies, and preferences in relation to the products that are being used. Likewise, the library needs to not only understand the intricacies of the product, but the company's support procedures. Apurely a la carte approach might lead to you to deal with three or four different vendors. It makes sense to acquire products from as many vendors as necessary to create the best possible environment for users, but to leverage existing relationships when possible.
We should also select products that will work together well. The way that applications share data and interoperate with the existing infrastructure may outweigh other features and functionality. The library may save itself a great deal of work by obtaining a set of products that were designed by the vendor to form an integrated suite. In theory, product suites should work better together than products purchased separately from different vendors. In practice, the level of integration within these suites may be less than expected.
Opportunities and Risks
The modern environment of complex collections and the multiple products to manage and provide access to those collections place the librarian in the role of systems integrator. We have to select, configure, and administer a number of applications to create an environment that meets user expectations. Yet, though the cost and complexity of library automation may be at an all-time high, the opportunities for serving users are as never before. The amount of content that we can deliver to users is unsurpassed. But there are risks involved. If the environment comes off as too complex and isn't user-friendly, the library may not see its resources used to their full potential.
