Libraries today insist that their major technology products not be closed and proprietary. Rather, libraries seek at least some level of transparency into a product's internal programming, allowing them to tap into its capabilities in ways beyond the user interfaces supplied. Procurement decisions increasingly factor in the degree to which a system is open. In this current phase of the industry where automation products have achieved a high level of functional maturity, their capacity for extensibility and interoperability have become important differentiating features.
Larger and more complex libraries especially benefit from the ability to extend the capabilities beyond the user interfaces provided with an application. They need to extract data for presentation in other contexts, create customized reports or analytics, or even create new utilities or apps based on the functionality or content of their principal systems. Data from the library's automation system can be repurposed in many ways throughout its website and related resources, ranging from visual scrolls of highlighted items to discipline-specific research resources.
Many libraries require reports or data extraction that may exceed the standard tools provided with the system. Some implementation scenarios of library automation systems may allow SQL-level access to the database for reporting, but as we will see, this approach can also be problematic. A robust set of APIs that allow access to all data elements seems the more ideal approach to data reporting and extraction.
It is unrealistic to expect that any system built to serve a broad segment of libraries would have every miniscule feature that an individual library might need for its specific needs. In some cases libraries can customize the code of the system to tweak its functionality. Systems based on open source software have this capability and even many proprietary products provide access to many internal components that can be customized. In either scenario, these customizations can be fragile, subject to disruption as new versions of the software are implemented. APIs provide a more stable and reliable approach to creating library-specific functionality. Depending on the completeness of the APIs exposed, it may be possible to create entirely new user interfaces based on the underlying system.
It is often important to have the capability to make connections among the applications within the institutional infrastructure in which the library resides. Common scenarios include the need to populate the integrated library system with patron records from a student records management system, institutional personnel systems or other sources. Financial data are managed within an ILS, but may also need to be reconciled with the enterprise resource planning applications or other business systems. To enable library systems to participate in a single sign-in environment requires interoperability with institutional authentication services. In the absence of some technical method to enable these systems to exchange data, considerable effort can be unnecessarily expended in the redundant manual rekeying of data.
Libraries have accomplished many of these interoperability scenarios through pragmatic methods such as the extraction and exchange of batch files of data. APIs or other data extraction tools can be used to prepare files where records are formatted according to prescribed specifications and then imported into the designated system in bulk. In some cases, systems may have complementary APIs that enable a more dynamic synchronization of data in real time. This dynamic exchange is unfortunately only rarely achieved. Even if the library systems expose the requisite APIs, many of the business systems in academic or municipal networks may still follow legacy architectures. I anticipate a time when libraries operate within more mature environments with a robust ecosystem of APIs that comes closer to realizing the potential of this technology.
Benefits for Smaller Libraries
Not all libraries have the interest or capacity to take advantage of these APIs or other interoperability mechanisms. Small and even medium-sized libraries may not have personnel with the technical skills needed to work with their system in this way, but rather use the system as delivered or work with its supplying vendor to make any necessary adjustments or interconnections.
While the larger libraries are more likely to make direct use of APIs, smaller libraries can also gain benefits. Even small libraries may have scenarios where their systems need to exchange data with third-party systems. Self-service equipment, scheduling or reservation applications, messaging engines for the delivery of library notices through voice or SMS, or other common library-oriented products may need access to the library's system, perhaps not accomplished solely through standard protocols, such as CIP2, NCIP, or Z39.50. It is important that even the products oriented to small libraries have the APIs available to third-party vendors who might offer of value-added products and services.
APIs for Multi-tenant SaaS
Technology products oriented to libraries are increasingly deployed through software-as-a-service, including those where all the users of the system share the same platform or codebase. These multi-tenant arrangements come with great benefits, but also pose some special challenges in customizability, extensibility, and interoperability.
For automation systems that a library installs on its own servers, providing access to data can be accomplished through direct access to the underlying databases. Because those databases are exclusively used for that library, fewer complications would arise from the library's executing SQL commands directly to read, or even write records to that database. Naturally, to ensure data integrity, great care needs to be taken when writing to the database, but any risk is contained to that library's instance of the system. By providing documentation for the database schema and enabling SQL access, the provider of a system can give a library unfettered access to the data, and this is a common practice for many library automation products.
Likewise, setting up interoperability with external systems can be managed in a fairly straightforward manner. Data exchange can be established with external systems, such as student record systems, or financial systems in a one-to-one relationship. While the methods used to accomplish the interactions between these systems might be complex, the data relationships usually can be mapped fairly easily.
One of the fundamental trends in technology applications for libraries is delivery through multi-tenant SaaS. Several of the new library services platforms, including OCLC World- Share Management Services, Ex Libris Alma, ProQuest Intota, as well as all of the index-based discovery services exemplify this multi-tenant approach.
In the multi-tenant SaaS deployment model, the data of each of the institutions serviced by the platform may reside in the same physical database, though aggregated from a functional perspective to ensure that each institution and their associated individual users can access only their authorized data.
In these situations organizations cannot be granted privileged access that would enable reading or writing data related to other institutions. It would be like giving one of the residences of an apartment building the ability to turn off the hot water for the whole building. Shared infrastructure, whether physical or virtual, must be administered for the good of all its residents. Therefore, multi-tenant SaaS platforms do not allow any of its users to use tools that directly address the underlying operating environment or low-level data structures.
Because low-level access of the operating system or database is generally off limits for multi-tenant SaaS systems, access to data outside of the user interfaces must be accomplished through APIs. For libraries used to the legacy approach of native SQL access, this reliance on APIs can seem quite restrictive. Especially in their early development phase, APIs that address all of the data and functionality of the system may not be exposed. But as API packages become more mature, they should be able to deliver access to library data in ways that meet or exceed that accomplished through direct database access tools. These APIs, for example, can include data integrity checks, transaction roll-back, or other functions not easily achieved through direct database access.
In this issue of Smart Libraries Newsletter, we feature two new initiatives to facilitate the use of the APIs. We cover Innovative's roll-out of their new suite of REST APIs and describe the new development environment that Ex Libris has recently launched. We note that other library-oriented technology providers also have well-established APIs or development communities.
OCLC has a Developer Network that includes access to documentation and tools for the APIs related to its World- Cat and WorldShare platforms and even has a team within its workforce dedicated to helping its members explore these tool. SirsiDynix has offered a command-line proprietary API for its Symphony ILS since 1995 and in recent years has developed a new set of APIs through its Web Services layer, developed for both Symphony and Horizon. Polaris has offered APIs for its ILS and provides resources for the development community within its customer base as well as a software development kit for third-party commercial applications. This set of examples, though not comprehensive, shows that APIs have become a fairly well established in the library technology arena.