Copyright (c) 2004 Information Today
|Breeding talks about the lib-web-cats directory, which does not only offer the general public an easy way to find libraries on the Web, but also provides trend data for studying library automation. The database tracks each library’s current automation system, any previous ones, and the years in which these systems were implemented. It also records whether the library implements its own automation system, gains access through a consortium, or relies on its automation vendor to host its system.|
One of my various professional projects is maintaining the libweb-cats directory of library Web sites and online catalogs on the Web. This directory, while it affords the general public an easy way to find libraries on the Web, also provides trend data for studying library automation. The database tracks each library's current automation system, any previous ones, and the years in which these systems were implemented. It also records whether the library implements its own automation system, gains access through a consortium, or relies on its automation vendor to host its system (see http://www.library technology.org/libwebcats).
I've also just finished a project that involved a detailed analysis of the library automation business environment in 2003. I tracked all of the major library automation companies in a survey that gathered extensive information about the kinds of libraries that acquired automation systems last year.
The data from these two projects confirm a major library automation trend that I've been watching for the last few years. An increasing number of libraries automate using shared systems rather than operating their own. Over time, the total number of library automation implementations will decrease, with each system supporting a larger number of libraries. We've long expected multiple libraries on a campus or all of the branches in a city or county to share a single system. It's increasingly common for libraries within geographic proximity or high-level organizational jurisdiction to work together as a consortium to implement an automated system. Today, more libraries are willing to use an automated system hosted by the vendor in an ASP arrangement.
Traditional library automation has evolved into a commodity service. It isn't glamorous, compared with digital library initiatives, library Web portals, metasearch systems, and reference linking environments that have grown to capture the interest of librarians as they consider ways to use technology to maximize their presence and value to their users. Core ILS functionality remains essential to efficient library operations, yet everything must be done as inexpensively as possible, and in a way that enables a library to extend its services and engage in resource sharing arrangements with other libraries. Many factors often lead librarians to seek out opportunities to share a system rather than to operate their own. I'll discuss a number of them in this column.
Local Control. While librarians feel the need to lower automation costs, they value their autonomy and the ability to maintain control of their automation environment. While all libraries are interested in reducing costs, they resist ceding their identity. A shared ILS implementation has to maintain the individuality of each library to the greatest degree possible, meet its basic automation requirements, and complement local policies and procedures. The degree of local control possible within a shared automation system varies. While some consortia leaders establish a rigid set of policies to which everyone must agree in order to participate in the shared system, others offer the ability to configure the system, to accommodate individual library preferences.
Economies of Large-Scale Implementations. Few technical barriers stand in the way of very-large-scale ILS implementations. Today's computer systems easily sustain automation systems that support large numbers of libraries. In previous times, lack of affordable computing equipment limited the overall scale of feasible library automation implementations. Now that an enterprise-level computer system-consisting of terabytes of storage, clusters of multi-gigahertz processors, and database engines capable of handling billions of records-can be assembled at relatively modest cost, hardware and software don't limit the number of libraries an automation system can support.
Here are some examples of large-scale consortial ILS implementations:
These are but a few examples of existing large-scale ILS implementations that demonstrate the ability of current systems to handle large numbers of libraries.
While large centralized automation systems represent a significant capital investment, the resulting costs per library are much lower than what it would cost each to implement its own stand-alone system. Costs for hardware, facilities, software licenses, technical support, and administrative overhead involved in a single central system can be significantly less than the offsetting costs involved in maintaining multiple independent systems.
More Features. Participating in a shared automation system gives you the ability to use one of the full-featured ILS's rather than a system with more limited capabilities. Especially for small libraries, the automation systems that are affordable as independent, standalone packages may lie a significant step below the top-tier systems used by large libraries and consortia in terms of functionality and sophistication. Although low-end automation systems continue to grow in their capabilities, they still lag behind the top-tier systems-especially in the realms of resource sharing, standards, and interoperability.
Lower Support Costs. By choosing not to operate its own stand-alone automation system, a library can achieve significant savings in technical support costs. The network and systems administrators needed to maintain a local ILS implementation command high salaries, funding for which can either be avoided entirely or directed toward other strategic technology projects. You can also eliminate facilities costs related to the data center environment, including adequate power protection, temperature control, and physical security needed to house a mission-critical server. Especially for small libraries that lack their own technical support staff, participating in a shared system makes good economic sense.
Hybrid Options Possible. Library automation in a consortium does not always mean having one centralized system. A number of consortia-especially those that include large libraries-may deploy a distributed server environment in which some of the participants operate an instance of the automation system. OhioLink uses this approach, with each of the libraries in the consortium operating its own copy of Millennium, supplemented by a central Millennium system that includes the holdings of all of the participants.
The ASP Alternative. Another variant of the shared system involves ASP, the Application Service Provider model, wherein the vendor hosts the library's use of its system. In this arrangement, the library does not install a local server, but rather relies on hardware operated by the vendor at its own data center. Using an ASP, the library operates the software via the Internet or a private network connection, not unlike a participant in a consortium. The ILS vendor assumes all responsibility for providing and maintaining server hardware, server administration, software upgrades, and other technical tasks. Opting to go the ASP route requires a very high degree of confidence in the library automation vendor. In reality, most of these vendors are better able to operate an industrial-strength data center and to maintain server hardware, operating systems, and application software than most libraries.
For librarians who want to enjoy the benefits of a shared system, yet do not have opportunities to join a consortium, the ASP model offers an attractive alternative. I've noticed an increased number of libraries choosing it. While ASP tends to appeal to smaller libraries, some medium-sized libraries, such as the Cobb County Public Library in Georgia, have also selected this approach.
Resource Sharing. Practically all libraries face budgetary constraints. Consortia membership allows them to do more with less, while offering their users significant benefits. Through a shared automation system, each library's users can conveniently search the collective database of all of the participating libraries. Participants in consortia generally allow reciprocal borrowing, and many will implement book delivery systems. Library users see great benefits. For example, patrons of a small library that supports a collection of less than 100,000 items can, by virtue of a shared consortial system, select from a virtual collection of millions of titles. Items ordered from a remote library might take a few days to arrive, although delivery within a consortium tends to be significantly faster and far less expensive than that for normal interlibrary loan requests sent to unaffiliated libraries.
One of the key issues in running a successful shared system is finding the right partners. The participating libraries must share a vision of automation and have reasonably similar operational procedures. And the more diverse they become in type and relative size, the more compromises they have to make.
While the prevailing trend is for libraries to join consortia, it's not unusual to see a library pull out of a consortium to implement its own system. The Rockford Public Library, for example, recently exited the shared catalog of the Northern Illinois Library System to implement its own stand-alone system. Among other factors, the librarians felt that the interests of their large, urban library did not meld well with those of the consortium of mostly small libraries.
Another consortium that went through recent changes is DALNET, the Detroit Area Library Network, which consists of a diverse mix of libraries in the metropolitan area, including the Wayne State University Library System, the Detroit Public Library, and a number of smaller libraries. It's apparent that the consortium wasn't entirely successful in meeting the needs of this diverse set of organizations, in that Wayne State recently dropped out of the shared Horizon system to implement its own Millennium system, and Detroit Public announced that it will be joining The Library Network, another local consortium.
As a rule, however, more libraries are joining consortia. As I look at the membership of the major consortia represented in lib-web-cats, the number of participants in each has grown significantly over the last 5 years. Though it may take a number of years to play out, I believe that the vast majority of libraries will participate in shared automation systems rather than run their own. The library automation landscape that I see 5 years from now includes far fewer libraries operating independent automation systems, and these large implementations will be provided by a relatively small number of companies. There are relatively few systems on the market capable of supporting large consortia. This trend will inevitably result in market share shifting away from companies that provide software for individual libraries, and toward those that offer systems for large libraries and consortia.
The prevailing forces in selecting a library automation system, and in determining organizational structures for supporting automation, center on increasing resource sharing while reducing costs to individual libraries. There will always be a contingent of libraries that, for very good reasons, will continue to operate their own systems. Still, I observe a strong trend toward shared systems, whether through large multilibrary systems, consortia, or ASP implementations. Especially now, as libraries face increasing pressures on their budgets, fewer have the luxury of operating stand-alone automation systems.
|Type of Material:||Article|
Computers in Libraries|
|Volume 24 Number 5|
|Systems Librarian Column|
|Last Update:||2012-12-29 14:06:47|
|Date Created:||0000-00-00 00:00:00|