A major development in the most recent phase of library technology can be seen in the emergence of library services platforms (LSPs). ILSs have previously stood as the prevailing model for the technology supporting the management and access of library collections and for the automation of library operations. These two approaches continue in parallel. While LSPs have attracted great interest by academic and research libraries, the ILS persists among public, school, and special libraries.
I anticipate that these differing models of library automation will coexist for quite some time. In the long term, ILSs may evolve to gradually take on more of the characteristics of LSPs. We already see the movement in that direction. ILSs are increasingly moving toward web-based interfaces and are offering more extensive sets of APIs. The concept of the platform, however, provides a technical architecture and deployment model consistent with current-day web applications and social networks with considerable potential to benefit libraries.
Platform Characteristics
The development of a new genre of products through technologies and architectures deployed in a platform differs in many important ways from previous generations of library software. This platform approach brings many of the characteristics seen in modern consumer and business applications and in the major social networks to library applications. Some of these characteristics involve technical infrastructure while others relate to the delivery of functionality and data resources.
Technical Infrastructure for Apps and Applications
The technical architecture of a platform usually follows a layered approach, with each layer operating fairly independently from others. The concept of a technology stack is not new and is fundamental to enabling a product or service to survive changes in any given software component, standard, or protocol.
An important aspect of a platform lies in its reliance on a lower-level layer of technical infrastructure, which provides behind-thescenes support for higher-level apps that provide more conspicuous functionality. This technical infrastructure is often implemented through an enterprise service bus, which provides a set of tasks needed by all applications (such as messaging, event management, and access to data stores). Rather than redundantly coding low-level services into an app, developers can make calls to the service bus. This approach not only simplifies application development, but it also provides a mechanism for different applications or units of functionality to share or exchange data and form cohesive workflows.
This low-level technical infrastructure shapes the capabilities of the platform, such as its ability to support multiple tenants, to offer consistent user interfaces among modules or apps, and to manage diverse types of data, as well as other broad characteristics. The technical components and interfaces offered by this infrastructure layer are of critical interest to developers, but they are transparent to users of the applications delivered through the platform.
Web Native
Modern platforms are intrinsically oriented to web technologies, both in terms of user interfaces (UIs) and technical interoperability. The user-interface toolkits and internal communications of these platforms are based on web-oriented technologies and protocols. This fundamental characteristic of modern platforms supports current expectations for the UI of library applications to be accessed purely through a web browser without the need for any additional software to be installed on a staff member's or patron's computer. This approach contrasts with applications initially created in the era of client/server computing in which graphical clients were installed on local computers, using SOAP or proprietary protocols to communicate with servers. External access to data and functionality would usually be offered through REST APIs, which use basic web protocols to transport the requests and responses.
Web interfaces, while native capabilities of platforms, can also be implemented for applications based on other architectures. Web-based online catalogs were quickly implemented for ILSs based on client/server computing following the advent of the web in the mid-1990s. More recently, ILSs are increasingly creating web interfaces for staff modules.
Designed for Multi-Tenancy
Platforms have the capability to support many different implementations of an application within a single instance. This deployment model contrasts with applications that require a separate copy of the software to be installed for each implementation. ILSs, for example, require each organization implementing the software to maintain a copy of it, installed on a set of physical or virtual servers. This approach means that each of the hundreds or thousands of organizations using the system has to install and maintain the software independently, including applying new versions and the administration of hardware and operating systems. With a multi-tenant platform, all users of the application participate in a single instance of the codebase and share the same version.
This concept of multi-tenancy offers substantial benefits to both developers of technology products and those that use them. For the providers of the platform, technical support is greatly reduced by only having to maintain one production version. New features, security patches, or bug fixes are implemented once for the benefit of all customers. Adding new customers involves only creating a new set of configuration details and allocating resources within an existing instance of the platform rather than an entirely new installation of the software.
Subscribing to a software service deployed through a multi-tenant platform also benefits the individual or organizations using it. Receiving updates is much more automatic and less disruptive since updates are usually deployed incrementally and with little or no customer intervention. It is also helpful when all organizations are using the same version of the software, especially in the library environment, in which interaction among sites using the same product is common.
Globally Scalable
Platforms are based on technologies that ensure they can continually expand in capacity to accommodate not only the load of any given implementation, but that of all users in aggregate. Platforms are not deployed on a single set of servers, but rather through highly abstracted infrastructure that can be distributed across as many hardware components in a data center as necessary and across multiple data centers spanning geographic regions. This distributive deployment model also means greater reliability. With redundant components and data centers, platforms can work around failures at almost any level.
A Toolkit of APIs
Platforms usually support a set of core applications delivered as a strategic product. These core applications are created by the provider's internal developers and are intended to offer a complete set of functionality and services. Platforms can also empower external developers, which may be interested in working with the product in ways beyond the core delivery. In support of this capability, platforms offer a set of APIs representing high-level and low-level services that provide granular access to the functionality and data residing in the core applications. In most cases, the core applications are created using the platform's APIs.
APIs can also be exposed to external developers, usually in a more selective and controlled way, to enable the creation of new services, apps, or reports that address specialized needs or areas of functionality beyond the delivered application. In this way, a platform is not just an application delivered by a vendor, but it can also be a toolkit for the creation of related services. This capability is consistent with the concept of platform-asa-service, but one replete with libraryspecific functionality and populated with relevant operational data.
Depending on the policies and business arrangements, apps created by third parties can be shared among other users of the platform. It may be possible, for example, for customer-created apps to be validated and certified and then made available as optional addons to other institutions subscribing to the platform.
Flexible Functionality
The technical infrastructure of a platform, as we have seen, hosts applications delivered as the core product. It can also host applications created by customers or other third-party developers. Platforms are agnostic relative to how the functionality of those applications is organized or deployed. Each provider of a product based on a platform will make its own choices regarding how functionality will be organized.
In the LSP arena, different alternatives are in play relative to the deployment of functionality. One model presents an all-inclusive suite of functionality in a very tightly coupled way. This approach emphasizes the unification of workflows able to manage many different types of resources from within a cohesive webbased staff client. Delivered as a comprehensive system, it follows consistent user-interface design and workflow patterns. All aspects of the system are inherently designed to work together. Ex Libris Alma and OCLC's WorldShare Management Services are delivered in this unified model.
A contracting model favors modularity. With this approach, each area of functionality can be addressed by an app or module. These modules may be created by the same developer as the platform itself or by third parties. Multiple apps may be available that address the same basic area of activity, providing libraries a choice regarding which best meets their needs. Apps that have become obsolete in some way or that do not meet expectations can be replaced with new ones. The recently launched FOLIO project follows this modular approach, envisioning a lightweight platform that can be populated with functional apps, which can be selectively activated by each library using the product.
Platform-Based Data Services
Platforms can not only host applications, but they can also house data services. The ILS model manages data related to each implementation. LSPs, in contrast, may host built-in data services available to all the organizations subscribing to the platform. These data services may include integrated knowledgebases of e-resource holdings, extensive bibliographic databases, shared vendor profiles, or other content resources available to all libraries using the product. Hosting content resources within the platform can enable more efficient workflows relative to that seen with ILSs in which such data sources must be provided externally with records transferred or imported as needed.
An Uneven Transition
Libraries have historically turned relatively slowly through the cycles of change in the broader information technology sphere. Lacking the resources of the general business and consumer arenas, technology products and services for libraries have not been on the cutting edge of change, but rather have followed a bit later as architectures become more mature and as acceptance solidifies.
In this current phase, web-based multi-tenant platforms have been well accepted in the broader IT landscape for quite some time. Development of LSPs in this vein commenced in about 2009, with these products advancing mostly among academic libraries. Other types of libraries continue to rely on ILSs gradually evolving from functional and technical designs rooted in the previous era. In the long term, I anticipate that the platform approach will dominate all aspects of the library-technology arena. I don't see a single path leading in that direction. I can imagine some of the current vendors creating new products through new platforms, evolving their current products into new architectures incrementally, or following a hybrid approach. A mix of revolutionary and evolutionary development will provide an interesting pathway as this phase of library technology runs its course.
