Libraries embrace collaboration as a fundamental value. Working with peer institutions and colleagues can be enormously beneficial in improving the capacity of a library to enhance its services. No library today can expect to directly own all the possible resources to fulfill the needs of its clientele. Almost all libraries participate in some type of interlibrary loan or consortial lending program to fulfill requests for materials not available in their own collections.
Taking collaboration on an even deeper level, some libraries opt to join a shared technology environment, rather than operate a standalone automation system. These shared technology environments can be based on an ILS or library services platform implemented for a consortium of independent libraries, for multiple campuses of a state or national university system, or for other libraries within the same geographical area or organizational jurisdiction. In recent years, shared systems have been on the rise and represent a strengthening trend toward deeper collaboration.
Benefits of Collaborative Infrastructure
Shared technology infrastructure affords participants the opportunity to gain a number of advantages. These benefits include a greater impact of collections, savings in technology costs, and operational efficiency.
When many libraries collaborate in a shared resource management and discovery environment, the aggregate volume of content can dramatically exceed what would be available to patrons solely from their home libraries. The number of items addressed in a default search may rise from thousands to millions. Patrons will learn about many resources that they would otherwise not have encountered if their query found only the holdings of the local library. Whether the content is for leisure reading or serious research, any opportunity to expand the scope of search will provide a more satisfying research experience. The process of fulfilling physical materials (requested by a patron) that are housed beyond the local library must be addressed and will incur some costs for routing and delivery. Fulfillment costs for non-local materials would be a fraction of the large acquisitions costs for any library to directly acquire the quantity of materials represented in collaborative collections.
Shared infrastructure can reduce technology costs. Instead of purchasing hardware and software for an independent, standalone implementation of an ILS, each participant pays a share of the collaborative environment. In addition to these direct costs, participating members do not necessarily have to provide technical personnel for systems administration or a systems librarian to configure and operate a local system. Some libraries may continue to employ individuals in these roles, but more of their work could be directed to higher-level activities or other projects.
In most cases, the implementation of a shared automation environment will be administered centrally, with those costs incorporated into the fees members pay to participate. Unless there are unusual circumstances, costs should be lower to participate in a shared system compared to individual implementations. This shared systems model also enables the personnel with expertise and talent in technology to channel their energies toward more patron-oriented services, rather than the almost neverending chores involved in managing a local ILS.
A shared environment also provides opportunities for streamlined operations. Activities can be selectively centralized or distributed. Some consortia using shared systems might provide fully centralized acquisitions or cataloging services. Many others are hybrid: Member libraries process some local materials, while core materials are handled centrally. It's also possible to remain entirely distributed: Each participating institution assumes responsibility for the acquisitions and cataloging of its own materials. Part of the appeal of shared infrastructure lies in this kind of flexibility. Those that want to reduce processing costs may gravitate toward centralizations, while those that need more local control can manage this work internally. Standalone systems stymie options beyond self-sufficient local processing.
These shared environments can open more options that make better use of subject experts or language specialists. Even when processing is distributed, organizations can designate individuals to work with specific types of materials. This approach can result in deeper expertise in each area.
One of the key advantages of shared infrastructure lies in its ability to facilitate strategic collaboration in building collections. Although many institutions may have informal agreements in which each is responsible for creating deep collections in specific academic disciplines, it is difficult to execute collaborative collection development when each library operates independent automation systems. Understanding what materials are held by partners and what may be on order, as well as performing collection impact analytics, can be timeconsuming when each institution has a separate system. A shared environment potentially makes this work much more seamlessly and offers built-in analytical tools to support collection development librarians as they make purchase decisions for library materials.
Trends in the Trenches
The practice of sharing systems has been around since the earliest phases of library automation. Examples include regional consortia and multi-campus academic institutions. While shared systems are not new, I observe considerable movement toward this approach among institutions that have previously automated independently. In addition, many libraries are moving away from local implementations by joining a consortium. There has also been consolidation among consortia, resulting in some large shared systems.
There are many examples of new collaboratively shared systems. The 23 campuses of California State University's system have recently opted to implement Alma collectively, moving from the previous configuration in which each campus operated its own automation system. The 40 publicly funded universities, colleges, and community colleges in Florida have announced that they will jointly implement a Sierra environment. Previously, all of the community colleges had shared an Aleph implementation. The universities once had separate implementations of Aleph, but that configuration was likewise consolidated. The eight public universities are in the process of implementing a shared Sierra environment, moving from individual automation systems. All the public libraries in Wales are moving to a shared SirsiDynix Symphony ILS. The academic libraries are switching from separate systems to a shared Alma implementation. These projects have been announced in the last year and most are still in the implementation phase.
The Orbis Cascade Alliance (a group of 37 colleges and universities in Washington, Oregon, and Idaho) completed its implementation of Alma in January 2015. This ambitious project was closely watched by academic libraries for other groups considering some version of this shared infrastructure strategy. I could mention dozens of other examples beyond these few.
In addition to these new large-scale projects, I observe another pattern of a fairly constant influx of libraries joining existing consortially shared ILS implementations. I especially notice that many small to midsize public libraries running outdated systems are moving to a shared ILS rather than implementing a new standalone system. Although there are some inexpensive systems available for small libraries, often, these libraries can take advantage of a much more sophisticated technology environment via a consortium, as well as provide its patrons with a significantly larger pool of resources.
Small libraries, in my view, have the most to gain from collaborative technology infrastructure. Those that serve small communities or rural areas may have small budgets and very little technical capacity. The resources they can offer to their patrons may therefore be quite limited, compared to libraries serving urban areas. Joining a shared ILS via a consortium can be a strategy for providing better resources to these otherwise underserved communities.
Scalable Technology
The patterns in which libraries participate in library automation were shaped, at least to a certain extent, by the limitations of technology in earlier times. In the days when automation systems serving very large libraries or consortia operated on mainframe or midrange computers, installations were concentrated in well-funded organizations. Those with sparse resources gravitated toward microcomputer-based systems, usually implemented in single library configurations.
Technology today can scale almost infinitely, with the ability for any given implementation of an automation system to support a large number of libraries. Current technology architectures can be used to create multi-tenant platforms in which a single instance of the software can support thousands of libraries. The increasing performance of hardware, clustering options, and other technical advancements enable products based on older architectures to support larger numbers of libraries in an implementation. The increasing scalability of technology supports the current trend toward more libraries gaining automation via shared infrastructure and fewer opting to remain with standalone systems.
Looking forward, I expect to see this trend continually strengthen. There will be a larger number of libraries participating in collaborative technology. Over time, there will be a smaller number of implementations of automation systems, each supporting a bigger amount of libraries. The numbers of libraries opting for independent use of an ILS will diminish. Companies and products able to support large collaborative deployments will find that they are better positioned than those more oriented to single-library implementations.
The trend toward shared systems does not necessarily lessen the viability of independent implementations for some libraries. I continue to expect a diverse range of automation strategies that are optimal for libraries with different strategic concerns, political realities, or operational concerns. In the multifaceted realm of library technologies, the growth of one thread of activity does not mean that others fall away.
Critical decision points present themselves infrequently. I would suggest that when libraries need to replace their current automation system, they consider the full range of possibilities. Those with standalone systems may want to explore opportunities for collaboration with some of their peer institutions. Simply replacing an outdated system with a newer one in basically the same configuration may be the path of least resistance. It might improve operational efficiency and address new areas of functionality, but it might only be a lateral move in the overall impact the library is able to introduce to its clientele. A move to a collaborative environment with other institutions may involve more disruption, but it might provide opportunities for strategic advancement.
