The Interconnected Reality of Libraries
We live in an era of social, enterprise-oriented, and increasingly cloud-based technology; a dramatic shift away from stand-alone isolated silos that previously dominated. Computing systems can flourish today only when built to easily exchange data and services. An application that stands alone may provide practical functionality but may not live up to the full needs of organizations, such as libraries, involved with complex computer needs. Most libraries today operate in partnership with a variety of other organizations, including their parent institutions such as universities, colleges, agencies, or local government; other peer libraries; and suppliers of all varieties. More importantly, library users access our services with an ever-broader array of devices - some with desktops, laptops, smartphones, or tablets and others through some intervening application such as their academic courseware system, corporate intranet, or even social networking sites such as Facebook. This reality of interconnectedness should shape the way that libraries adopt technologies as well as guide those who create software for libraries.
This inherent presence of interconnected organizations drives the need for library technology components that embody this quality. I think that anytime a library buys or builds some new piece of its technology infrastructure, one of the foremost requirements should involve its ability to fit into this broader environment. The automation strategy of most libraries involves a growing body of software applications, often acquired over time to meet the expanding scope of library collections and services.
The typical scenario begins with the procurement of an integrated library system. This genre of software was originally created as the comprehensive management tool for libraries, though conceived back when print collections prevailed. The transition toward increased involvement with electronic resources and digital collections brought the need for a continually expanding roster of specialized software. Link resolvere based on OpenURL and federated search tools that provided functionality needed for managing access and electronic resource management systems emerged to aid with back-room management tasks. Digital asset management systems, institutional repositories, and document management systems deal with content not well-handled by the ILS. Many libraries supplement their automation systems with third-party self-check stations, anti-theft security systems, or sorting equipment.
In more recent years, the inadequacy of library catalogs and other interfaces offered to patrons sparked interest in a new generation of discovery interfaces. Facing everproliferating website content and the need for more consistency in presentation, many libraries have adopted content management systems. Blogs sprouted as a vehicle for continually updated content and to lend personality to a library's web presence. Wikis, intranets, and shared file systems house documentation, procedures, and other data that library personnel need for their work. In addition to specialized library software, personnel make extensive use of general business software such as email, word processing, spreadsheets, and other productivity tools. Some use interlibrary loan lending and borrowing management systems or other resource-sharing utilities. While smaller libraries tend to make use of only a few items on this list, a larger library might deal with them all - plus others.
The cumulative impact of sustaining so many separate technology components presents an enormous burden on a library's personnel resources-both on the IT staffers that handle the technical issues and on the personnel that operate each respective tool in their daily work. Managing a large collection of stand-alone, isolated, and uncooperative applications can strain any library's IT support capacity. To the extent that each separate component can integrate nicely with the others, the overall load of support will lighten, and the benefits to library personnel and users will increase. I see great advantage in moving away from piecemeal automation toward assembling a unified technology platform.
But advantages of integration lie beyond efficiency of support. The work performed by each staff member in the library isn't done in isolation. Software used in one part of the library will have a direct or indirect impact throughout the organization. Back when all library work focused on the ILS, the needed interconnectivity was built in. But in today's environment involving multiple systems requiring additional effort to ensure proper data flow, that is not the case. To the extent that the data handled within each specialized application carries through other relevant systems, it improves the performance of the larger organization. This organic approach also benefits library users in that all aspects of information relating to library collections and services can more easily be exposed through the interfaces that face library patrons.
I'm not necessarily thinking about moving back toward large monolithic systems that encompass all aspects of computing within a library. We will continue to rely on many different specialized applications. Rather, I'm hoping for applications that embody a set of characteristics that make them easier to manage and that are designed to readily communicate, or interoperate, with a broader fabric of applications that together form a library's strategic technology infrastructure.
Intelligent Handoffs
It's essential for each software application to hand off some routine tasks and to concentrate on its unique specialized functionality. The mentality of a stand-alone application results in many applications replicating functionality. An obvious example involves authentication. So many library applications have their own self-contained mechanisms for controlling access, such as a database of usernames and passwords, that have to be populated and maintained. A more enterpriseoriented approach makes use of a single, highly secure authentication service that manages the login process for any application. When many different applications are able to hand off authentication to a service provided externally, it makes the system manager's job easier and relieves users from having to manage many different passwords. The same kinds of handoffs might apply to financial functions handled by an institutional accounting or enterprise resource planning system.
Many library-specific applications already handle these handoffs. Self-check stations, for example, perform circulation, handing off each transaction to the ILS through SIP2 or NCIP protocols. Interlibrary loan management systems might use NCIP for any necessary communications with the ILS, yet I observe that many libraries must perform manual operations involving resource sharing and their ILS. While there are many examples of ways that library-specific applications do communicate with each other, I also observe many gaps, especially in areas where no specific standard governs interoperability.
Service Layers
Web services and other APIs provide the means for enabling communications among applications. My regular readers will recognize this topic as one that I mention frequently. In addition to the interfaces delivered for public access or staff operation, applications need to be enabled with these computer-to-computer communications mechanisms to maximize their benefit to the enterprise. More recently created applications may be built from the ground up using a service-oriented architecture (SOA) where its internal design makes use of services as building blocks to create higher-level functionality SOA gives applications an inherent advantage to interoperate with other systems.
Much of the software that libraries use was created prior to the advent of SOA. These legacy applications, however, can be adapted to a modern enterprise environment through the creation of a layer of services that exposes data and functionality through web services, a special kind of application programming interface (API) based on XML, HTTP, and other web-oriented technologies. I have seen a great deal of development among the ILS vendors to extend their products with web services.
Benefits to Library Users
A nicely orchestrated set of applications, all tied together through service layers, sets the stage for creating a library web presence more unified and user-friendly than otherwise possible. Many library websites offer a menu of options to their users, each with their own idiosyncratic behavior, look and feel, login requirements, and separate user profile. I often observe, for example, library web environments that involve separate profiles in the web-based online catalog for viewing items charged or placing holds or recalls, in the discovery system for managing saved resource lists, and in the interlibrary loan system for placing requests. We shouldn't just offer a menu of applications and assume that patrons will figure out the ones that they need for the problem at hand. We need to work toward an environment that brings library services together in a more integrated style.
An ideal approach might involve finding ways to deliver all the services of the library through a single interface that operates with each of the different back-end servicers behind the scenes through web services. I see the beginnings of this approach in the current genre of discovery interfaces. These products do a nice job of addressing all the different components of library collections, but their ability to serve as the single interface for all library services seems to be less complete. My vision for discovery interfaces has long been "a single point of entry for all the content and services of a library." We're getting there on the content; much remains to be accomplished with the services.
The transition of collections toward new media and formats has dramatically increased the complexity of the work that takes place in libraries and the technology needed to support that work. It's also resulted in complexity in our offerings to library users. An evolving transition to software architectures designed for interconnectivity is necessary if we are to find much-needed efficiencies in the way that we provide technology support for library operations and to enable the creation of end-user interfaces that deliver our services on the web in more powerful and more elegant ways. This transition will happen gradually and will find momentum as libraries buy and build software that not only meets the functional requirements at hand but also embodies these much-needed qualities of interconnectedness.
