Library Technology Guides

by Marshall Breeding

General Introduction

Libraries depend on their technology environment to support their operations and to describe and provide access to their collections. Almost all make use of multiple technology applications, provided by different vendors, which must work together effectively and efficiently. Systems not able to integrate fully into the organization's technology ecosystem usually result in duplication of effort, require manual processes for synchronizing data, and frustrate their users through separate logins.

The need for technology components to work together well drives interest in open systems. This term does not necessarily have a precise meaning, though it describes capabilities to easily connect to other systems, providing mechanisms for data exchange, and to enable its users or implementors to fully access data structures, and to enable programmatic access to functionality and data. This concept contrasts with closed systems that lack effective ways to interact with a system's data or to extend its functionality.

Open systems allow organizations to gain access to data and to create new functionality beyond what is directly delivered in an application. Libraries expect their systems to come with robust functionality accessed via the built-in user interfaces. Beyond these user interfaces, most organizations also need to move data in and out of their applications through automated scripts or through real-time interactions with other systems. Application Programming Interfaces, or APIs, are the technical mechanism expected in modern software applications to enable interoperability, access to data, and to support the creation of scripts or modules to perform related functions.

In the last decade, a large portion of academic libraries have shifted from integrated library systems to library services platforms. These new products provide an updated approach to library automation and resource management consistent with the current realities of academic libraries. These products aim to address complex multi-format collections, where investments in electronic resources generally exceeds that of print materials. This new generation of products are deployed through multi-tenant platforms, consistent with modern enterprise applications in most business and non-profit sectors.

Multi-tenant platforms come with a different approach to interoperability and extensibility relative to previous generations of applications. Integrated library systems, for example, are usually installed on a server cluster dedicated to a single organization, such as a single library, a multi-branch library system, or a consortium. Server-based applications can implement APIs to provide access to data and functional elements, but they can also enable direct queries to the native database structures, such as through SQL queries. Multi-tenant applications accomplish extensibility and interoperability entirely through APIs. Since the platform serves multiple organizations, direct access to its native databases would be inconsistent with the boundaries that must be maintained with institutional and individual data. The absence of root-level access to the technology infrastructure, including direct access to databases means that multi-tenant platforms must provide equivalent alternatives via APIs to achieve the needed levels of interoperability and extensibility. Reliance on APIs has become the norm for modern business applications. In the library arena, APIs have likewise become the expected mechanism for enabling open access to data and functionality.

This white paper explores the approaches taken to achieve open systems in the academic library arena. Both proprietary products and open source software can be designed and deployed to enable interoperability and extensibility and we examine some of the relevant differences in terms of practical capabilities for extensibility and interoperability. This report focuses primarily on the differing approaches to openness provided through library services platforms.

Enterprise applications developed under an open source license naturally are considered open since programmers and software developers have access to their internal source code. But if an open source application does not also offer extensive APIs, it lacks openness in a more practical sense. A proprietary application lacking APIs likewise defies practical interoperability and is a closed system. Whether open source products overall achieve a higher level of practical openness depends on specific implementations and on the strength of the APIs delivered versus relying on access to source code.

APIs represent the primary pathway for interoperability regardless of whether the system is offered under an open source license or if it is proprietary software. It's not access to the source code that makes an application open in a practical sense, but rather its APIs and related infrastructure, such as documentation, an environment to develop, test, and deploy coding to exercise the APIs, and communities of developers to share expertise and programs. Meaningful interoperability depends more on the strength of the APIs exposed by a system more than access to its internal source code.

Configuration versus Customization

Many organizations seek customized solutions that can be shaped to meet their specific needs. The pragmatic approach for deploying applications to meet the differing operational requirements cannot be effectively achieved through the creation of different versions of the software for each organization. Rather, applications must have effective mechanisms for configuration and extensibility that enable the core version to serve diverse organizations. The creation of ad-hoc specialized versions of software to achieve customization lacks the sustainability compared to open mechanisms of robust parameterized configuration and the ability to create extensions via API frameworks.

Organizations require that their technology systems be tailored to their specific needs. These applications must accommodate the specific business rules, workflows, data structures, branding, and other specifications stipulated by the organization. Implementation involves a series of procedures to configure and populate the application. Data from incumbent systems is exported, transformed, and loaded. System administrators select detailed options and parameters to configure the application for the organization and use scripts or other tools for loading data. Configuration and migration generally do not require access to the internal coding of the application and are accomplished through tools delivered with the application or that can be created based on documented data structure requirements.

This process differs from customization, which involves creating unique changes or versions of the software. Such customization might be used by organizations with distinct operational requirements that differ from what the application was designed to accommodate and that cannot be accomplished through the standard system settings and parameters. Customized software requires access to the source code of the application, or a willingness of a vendor of a proprietary product to create alternate versions for specific customers. In an open source development project, specialized features or customizations can be contributed back into the standard distribution of the application. As new versions of the software application are released, customizations created for or by specific organizations can be incorporated into the main version and may benefit others that implement the product. Customization through the creation of alternate versions of a software product involves a substantially more complex process than configuration. Developers of both open source and proprietary products aim to accommodate differing needs of diverse organizations through configuration rather than through variants of the application itself.

Customizable software is not a sustainable practice. It is not practical to create variations of an application to accommodate specialized requirements of an individual organization. Rather, vendors provide an application that can be configured to meet the different needs of each organization implementing the software. All the permutations of business rules and policies must be handled through configuration options, as well as interconnectivity issues, branding, or other common requirements.

Different flavors of open

The meaning of the term “open” varies by context, such as whether applied to content or technology.

Open access applies to content. Is the item readily available to all users on the Internet, or is it restricted to those that pay a subscription fee? In the realm of scholarly publishing, open access takes many forms and is a complex topic outside the scope of this report.

Open source software allows individuals or organizations access to its underlying programming code. The various open source licenses specify the specific terms of use, modification, and redistribution. Some licenses allow the software to be used on commercial or propriety applications. A variety of different licenses govern the use of open source software and developers must carefully navigate what is allowed or not depending on the license associated with any given application.

Open source licenses specify whether the software may be embedded in proprietary products and what disclosures or source code availability are required. Proprietary systems often rely on at least some open source components and many open source licenses explicitly allow commercial use in proprietary products.

Many library products have been developed and released under open source licenses, including Koha, Evergreen, FOLIO, VuFind, Blacklight, and many others.

In contrast, proprietary software is not deployed in a way that gives the organizations or individuals using it access to the underlying programming code. The absence of access to source code does not necessarily mean that a proprietary application cannot provide robust mechanisms for interoperability and extensibility.

With modern business applications, organizations expect functionality and access to data to be expressed both through user interfaces accessed by people and through application programming interfaces enabling interactions among various technical components. This level of openness is expected regardless of the product's software license.

Pragmatic openness

Some of the characteristics of a technology service that embody practical openness include:

• The ability to achieve extensibility and interoperability with moderate levels of technical expertise. Individuals with knowledge of a scripting language should be able to perform tasks such as extracting data, creating statistical or analytical reports, load data, create tools or apps that perform useful tasks not easily accomplished through the user interfaces.
• Create feeds or connections among related systems, such as loading patron records from institutional student account or personnel systems.
• Create alternative user interfaces for specific areas of functionality. A library may want to create an alternative interface for its online catalog or interfaces for making changes in sets of bibliographic records.
• Ability to interact with institutional authentication services or to participate in cross-institutional federated authentication
• Ability to implement automated transactions with suppliers or other business partners, using standards such as EDI or through API interactions.
• Ability to automate transaction with institutional financial systems, such as transferring transactions and balances to a bursar's office
• Support for standard protocols used by self-service stations and automated material handling equipment

Practical openness requires thoroughly documented APIs that clearly specify the requirements for any request and the elements returned in a response. Ideally the environment will include a safe sandbox environment to develop and test coding that interacts with the API in addition to the production version with live data.

Customizations or specialized functionality can be accomplished in an open source product by making changes to its internal code. While modifying the application itself may be seen as enabling a deeper level of openness, it involves a complex process. Modifying the internal coding of an application requires a higher level of technical skills, more on the order of a software engineer than a mid-level programmer. Modifying an application in this way requires a deep knowledge of its internal architecture and data structures. Other complications include how any changes to a local version may or may not be contributed back into the main trunk of the source code.

Insiders vs Outsiders

Discussions of openness and access to the internals of a product evokes the concept of who has access to its internals coding and data. Development Insiders have access to the internals of a software application. In an open source environment, any person can access the source code underlying an application. For proprietary applications, only the developers employed by the vendor have access to the source code and its internal infrastructure components.

Open source software enables outsiders to participate in the development of the platform.

In the era of library services platforms, openness takes on a different set of characteristics.

Platform characteristics

Library services platforms have been deployed as a single global multi-tenant platform and all using the same version of the software. This single codebase approach of a global multi-tenant contrasts with single tenant server-based applications where the version of the software may differ among the many instances of the program used across institutional customers.

Some of the relevant issues related to multi-tenant platforms include:

• A single codebase serving all organizations using the product. A unified codebase means that all users of the product are on the same version of the product and see the same interfaces and features. This approach simplifies maintenance and support for the platform provider.
• Platforms can be deployed through multiple global data centers. Such a distributed deployment enables more efficiency in resource utilization compared to concentrating all global users onto a single instance.
• A distributed platform can take advantage of load balancing among instances in addition to the techniques implemented within each instance to allocate and deallocate computing resources according to current and anticipated transaction loads. Cloud computing technologies are designed for elasticity of computing resources within a platform.
• Coordinated instances, where each runs the same code base, aggregates globally shared data resources, and segregates institutional data.
• Segregation ensures that organizations are served through data centers in their region or specific country, satisfying policies or legal requirements as well as optimizing bandwidth. Serving organizations from a data center in a globally distant region could increase latency and would be more vulnerable to communications failures on the internet. The global distribution of a multi-tenant environment is mostly transparent to users, which have the same experience of the product regardless of their geographic zone.

Note: Ex Libris Alma and OCLC WorldShare Management Services have been created as globally distributed multi-tenant platforms. FOLIO, an open source library services platform, though multi-tenant, has been designed for multiple implementation scenarios. As such, multiple instances of the platform have been implemented and each may be based on different modules and versions of the software.

For multi-tenant platforms, openness must be accomplished through APIs. Giving customers access to the underlying infrastructure of the active instance creates risk for all its users. Ongoing work to create new features or upgrade technical components must be accomplished through carefully controlled development processes that include rigorous testing and quality assurance.

For proprietary products, ongoing development remains entirely within the control of the vendor. Customers do not have access to the underlying programming source code or the lower-level infrastructure components. Customers of a multi-tenant product do not necessarily even know the technical details involved, such as the hardware resources, operating systems, programing languages, code libraries, database engines, or other infrastructure components. Since users of a proprietary multi-tenant platform do not normally have access to the internal details of a platform, APIs must fulfill all the requirements for interoperability and extensibility.

Ideally, every aspect of functionality and every data element addressed through the user interfaces would be addressable through the application programming interface. Programmers outside of the vendor can exercise the capabilities of the API through documentation that details each possible request and response.

Programmers using the APIs do not necessarily need to know the details of the internal workings of the platform. Likewise, platform developers must accommodate any programming languages or applications used to access the APIs.

Multiple layers of control must be in place to ensure that no damage can result from the user of APIs. Every program script accessing an API must be extensively tested, especially those that create or modify data elements. Access to an API must be controlled by the same authentication as user interfaces. Programmatic access to the data and functionality cannot bypass the controls in place for its human users.

Multi-tenant platforms based on Open Source Software

Products based on software developed and released under an open source license represent one approach to open systems. Applications released under an open source license necessarily provide access to the underlying source code enabling programmers to examine its internal workings, including the business logic, data structures, or other technical components. Each open source license comes with different requirements beyond the basic freedoms to access the full source code, make modifications, and use or distribute new versions. Enterprise systems created as open source projects tend to involve development teams that include software engineers, programmers, as well as specialists in quality control and documentation. Organizations implementing the software do not have to be part of the development team.

Applications based on open source software must include the same types of interoperability mechanisms as proprietary software. Organizations implementing the applications will want to take advantage of standard protocols and APIs rather than modify the application itself. An open source product that does not include well-documented APIs and support for industry standard interoperability protocols would not meet the functional expectations of open systems.

With open source products, there are few restrictions on access to the codebase. Any person from any organization can download the source code, view its internal workings, and even make modifications. Modified versions can be used by the organization and shared with others.

For any given active implementation of an open source platform, access to the codebase may be restricted to authorized developers. Production instances must be deployed in a carefully controlled environment that protects the integrity of the underlying data both through direct access and through programmatic access. Working with the code of a specific instance of an open source platform involves challenges, especially in a multi-tenant environment. Is it not appropriate for programmers from one institution to gain technical access to the data related to other institutions that share an instance.

Interoperability

Interoperable applications include mechanisms to communicate with other relevant systems that participate in a technology ecosystem. In a library context, these relevant systems may include other components used directly by the library, components within the campus environment, or those associated with external service or content providers. Interoperability can be accomplished through support of standardized protocols or through APIs. Organizations increasingly rely on interoperability mechanisms among the multiple applications and components that comprise their technology infrastructure.

A few of common interoperability scenarios in the library context include:

• Single Sign-on. It is expected that applications used by library personnel and users take advantage of an institutional authentication service rather than relying on separate usernames and passwords. Some common single sign-on frameworks include Microsoft Active Directory, the open source Central Authentication Service, and Oracle Identity Management.
• Communication with self-check equipment or automated material handling equipment usually relies on the SIP2 protocol, which is a well-established feature in library management systems.
• Search and transfer of bibliographic records can be performed using the Z39.50 protocol.
• Creating alternate discovery interfaces, often using frameworks such as VuFind or Blacklight. The DLF ILS Discovery Interface Task Group (ILS-DI) addressed the mechanisms needed to support interoperable discovery interfaces.
• Interlibrary Loan and resource sharing: the ability to participate in external ILL or resource sharing networks through standard protocols such as NCIP, SIP2, Z39.50, ISO 10160/10161, or through API transactions
• Inventory Management Systems: interface with the inventory management systems used in high-density storage facilities
• Student records: the ability to synchronize data for students through the institutional student account management systems.
• Financial Records: Exchange of financial data with institutional accounting or finance systems.

Libraries bring very high expectations for interoperability among the systems that comprise their technology environment. The library services platform or integrated library system delivers the core functionality needed to manage a library's operations and collections.

Some libraries may use only the user interfaces as delivered by the vendor for the operation of the system. It is expected that any product work well as delivered without the need for additional programming to achieve expected functionality.

Organizations expect application programming interfaces to enable automated access to data and functionality. Efficient interoperability among related business systems is essential to avoid duplication of data and effort, both for library workers and for patrons. No data should have to be created manually that exists on other applications within the institutional ecosystem or with business partners.

Extensibility

Even for the most complete applications, some institutions will benefit from some specialized functionality not part of the delivered product. Although vendors continually create new features, including those requested by individual customers or user groups, there will always be some gaps. While it is not feasible to create customizations of the software product itself, additional tools and functions can be created that fulfill specialized use cases.

Some platforms support the ability for plug-in modules developed by their customers or business partners. Organizations with specialized needs may be interested in creating modules that can be installed in their business applications. Building Blocks for the Blackboard Learning Management System are an example of this type of platform extension.

Extensions can be created to the delivered products by developers at customer sites, exercising the API framework of the platform. These extensions can be created in various ways, usually as scripts run on servers external to the platform. An alternate approach, described below, involves apps that operate within the platform. This method requires the provision of a specialized framework that enables customer-created apps to safely operate within the vendor-provided platform.

Authentication and API Keys

Access to data and functionality on a platform via its APIs must be carefully controlled. The standard approach used for access to APIs involves the use of a developer key, tied to a specific institutional identity which limits requests to the data and functionality associated with that organization. APIs do not enable access to data beyond that authorized through user interfaces.

In addition to the developer key, some functions may require more granular authentication and authorization. Special authentication may be needed, for example, for access to financial data within the acquisitions components of a platform.

Some platforms enable access to a sandbox to let programmers study the APIs and to create and test code.

Note: Ex Libris provides an API Console in a sandbox implementation of Alma and other products with a guest developer key. This allows anyone to learn and experiment with the APIs even if they are not a direct customer. (https://developers.exlibrisgroup.com/console/). Some limitations apply: “The Guest Sandbox is our demo environment. Users who do not have an institutional account can run our APIs and apply the GET method to retrieve results from our demo environment. However, guests cannot apply the POST and PUT methods.”

Note: OCLC offers a developer's API documentation resource: https://developer.api.oclc.org/. Access to APIs requires an authorization key. No guest access offered. Documentation to the APIs is available without authorization.

External Scripts and Apps

A platform offering a robust set of APIs enables the creation of scripts, applications, or interfaces that operate externally. These tools are hosted on a separate device or server and address the APIs exposed on the platform.

The environment that hosts a script or application accessing the APIs of a platform can be comprised of any combination of technology components. The only requirement lies in being able to correctly construct requests and process responses. The independence of components offering APIs and those consuming them represents the essence of interoperability.

In-platform Apps

Another approach to openness involves extensibility through apps that run within the platform itself. Rather than operating externally, these apps are installed within the platform. This approach resembles the concept of apps installed into mobile devises based on iOS or Android. These apps must be created within a specified framework of programming conventions and security controls to ensure that they operate correctly and cannot destabilize the platform or misuse data. Most installable apps must be validated and certified by the platform vendor before being added to its app library.

In-platform apps represent an important advancement of extensibility. Once developed, validated, and deposited in the appropriate app library, these apps can be activated and used without the intervention of developers or technical experts.

The architecture supporting installable apps enables the level of extensibility envisioned for open source applications within a proprietary platform. This approach enables extension of the product with customer-created functionality without the need to work with the source code underlying the platform.

Ex Libris Cloud Apps was featured in the September 2020 issue of Smart Libraries Newsletter:

The concept of user-installable apps has become a basic expectation of modern computing, especially on mobile devices. Both the Apple iOS and Android mobile environments make it easy for persons to find, select, and install apps made available through their respective app stores. Installing these apps does not require technical expertise and safeguards are in place to ensure that the apps will work correctly and not crash the device.

Ex Libris has recently released a new framework on its software platform that emulates the app paradigm experienced in the mobile arena. Ex Libris Cloud Apps brings installable apps into the environment of its strategic products. Apps can be created and deployed for any of the major products running on the “Ex Libris higher-ed platform,” which includes Esploro, Primo VE, Leganto, Rialto, and Rapido, in addition to Alma. The new framework enables Alma users to find, select, and enable apps without technical intervention. These apps, created by Ex Libris customers, give Alma users an extended set of tools to work more efficiently or perform specialized tasks. These apps run within the Alma platform and are used directly within the Alma staff-use interface, inheriting context such as authorizations and preferences.

This app framework enables the creation of functionality beyond what is built into the core products by the company's developers. Enhancements and new features for core products such as Alma must be suitable for the entire customer base. Even though the ongoing development relies on customer recommendations, many bits of functionality may not be appropriate for all sites.

Apps created by the community of developers from customer sites address specialized scenarios. Ex Libris has cultivated, from its customer base, programmers and technologists interested in working with APIs and other technical aspects of its products. The company launched its Developer Network portal in April 2014 to bring together documentation and other collaborative tools to support technical collaboration with its customers.

Assistance with apps comes through the Ex Libris Developer Network. This model of community support is well established among the users of Ex Libris products. While Ex Libris personnel participate in the Developer Network, the model of collaborative support differs from the standard channels of support associated with the company's core products. The concept of apps is not new to Alma. In May 2019 Ex Libris introduced an environment, branded as the App Center, in which apps ran on external computing environments, such as local server or cloud infrastructure operated by customer sites.

Cloud Apps brings a significant change in that its apps run completely within the Ex Libris platform, enabling their activation and use to take place entirely within Alma's interface. Cloud Apps are accessed through a new icon in the Alma toolbar. Selecting the Cloud Apps icon presents the apps currently installed. Users can browse or search for additional apps that can be activated. Each app listed includes its name, a brief description, its developer, any applicable terms of use, and a button to install it.

The new Cloud Apps framework will be deployed in the August 2020 release of Alma. More than 60 apps are currently available through the App Center. A subset of these apps has been developed as Cloud Apps; others are extensions that operate outside the Ex Libris cloud. With the Cloud Apps framework, the apps run within the Ex Libris platform infrastructure and are fully integrated into its user interfaces. Apps operate according to the context of the current display.

Some apps automate routine tasks to improve efficiency and reduce manual steps. These are similar to macros or keyboard shortcuts used with other systems. Combining multiple steps of a task reduces times waiting for a system response. Others interact with external resources to bring data into Alma.

[Breeding, Marshall. (2020). Ex Libris Introduces Cloud Apps. Smart Libraries Newsletter 40 (9), 3-6.

Note: The Ex Libris App Center includes tools that operate externally as well as Cloud Apps that can be installed into the platform. Deployment of a Cloud App involves the site administrator authorizing use of the app for that organization, after which any user can activate the app for use within their Alma profile. Some of the Cloud Apps provide tools or short cuts for staff-oriented workflows, others simply tasks for system administrators. Currently over 40 Cloud Apps are available for Alma. (https://developers.exlibrisgroup.com/appcenter/?search=&products=alma&type=cloudapp)

The following table presents the operability characteristics of the three products within the library services platform category.

Development Networks and Communities

The creation of software or related tools benefits from the collaboration and coordination of those involved in development. Development communities include individuals involved in a variety of roles ranging from highly technical work such as programming or technical integration, to creating documentation, testing, or other administrative tasks. Coordinating the activity of the individuals and organizations involved in a software project avoids the duplication of effort and can help prioritize development agendas.

The development of proprietary software takes place within a vendor or company, with executes that work according to its internal procedures and priorities. Users of the software may be able to give input on new features or enhancements but are not directly involved in development.

Products based on open source software usually have communities that span multiple organizations and individuals involved in development, documentation, and testing. These development communities ideally have some type of governance to guide priorities and to set a roadmap for new versions and enhancements.

Developer networks can form surrounding proprietary products. Although development of the product itself remains in the domain of the vendor, customers and business partners benefit from coordinated efforts as they create tools and extensions based on the APIs of a proprietary product.

A developer's network includes the community of interested individuals and organizations. The vendor for the product may also supply technical infrastructure to support its developer community. This infrastructure can include a variety of components including:

• Code repositories to share completed components among interested parties
• Documentation for APIs or other aspects of the product needed to support the creation of tools, system connections, or extensions
• API sandbox to enable developers to test program code
• Communications channels to enable developers from customer organizations to communicate among themselves and with experts or developers from the vendor.

With an open source project, developer communities generally focus on the development of the product itself, which will also include creation of APIs and tools that use them. Developer networks related to proprietary products focus on the creation of tools and extensions. Both styles of software benefit from collaboration among developers, both within and beyond those directly involved in creating the products. It is important for development networks to include technologists from organizations implementing the product as well as those involved in its creation.

User Groups

User groups represent another important aspect of the communities surrounding a strategic technology product. Such organizations have emerged in many different business sectors and have especially been an important aspect of the library software arena. User groups have been established for many of the major library technology products. Some of the most prominent include:

• COSUGI: Customers of SirsiDynix Users Group, Inc.
• IUG: Innovative Users Group
• ELUNA: Ex Libris Uses of North America
• IGeLU: International Group of Ex Libris Users
• EBSCO User Group
• KohaCon: international conference of Koha developers and users
• OCLC: Global and Regional councils focus on governance and strategy, the OCLC Community Center focuses on OCLC product users, and OCLC holds user group events

User Groups can foster collaborative interactions between a vendor and the organizations using its products. In most cases, the user group will be legally independent from the vendor. This independence ensures that the user group operates in the interests of the organizations that have implemented the products, articulating enhancement priorities, and providing constructive feedback. The relationship between a user group and a vendor will often include a formal process where its members select and prioritize a set of enhancements for the respective products. Execution of enhancement recommendations varies, though vendors generally strive to include customer-based enhancements in their short and long term development agendas. Some user groups have legal agreements with the vendor requiring some or all enhancements to be fulfilled.

Note: IGeLU and ELUNA have implemented an enhancement request process called NERS.

These organizations can be effective channels of communications in both directions. Customers can provide input and insight regarding technology products. Ex Libris and IGeLU have a binding product development collaboration agreement that requires the company to respond to enhancement requests:

The agreement formalizes principles of collaboration between Ex Libris, a ProQuest Company, the Ex Libris Users of North America (ELUNA) and the International Group of Ex Libris Users (IGeLU) on products which Ex Libris develops. Started in 2008, the agreement has been revised a number of times. The agreement is unique in the industry in that a vendor and its community organizations have an explicit agreement of their roles in the product development process. This agreement ensures community requirements are met through a formal enhancement voting process organized by the community usergroups.

summary; full agreement.

Other user groups also have formal processes for creating enhancement requests and formal or informal expectations on how these requests become part of the vendor's development roadmap.

Cost and Value Issues

The costs and value propositions of the different software development and deployment modules are complex. Since product costs, and related terms tend to be confidential and even protected by non-disclosure agreements, direct comparisons are not possible. Some general points can be made about the types of costs, efficiencies, and related issues can be mentioned.

Multi-tenant library services platforms:

Multi-tenant platforms make efficient use of computing resources. Only incremental increases in infrastructure resources are needed for each new site deployed on the platform rather than whole copies of an environment involved in new installations of a single-tenant or server-based product. The elasticity of platform technology reduces costs for vendors for computing resources and simplifies their technical maintenance and support costs.

Customers pay for the use of a platform-based product through a single comprehensive subscription fee. Costs for the initial year will also include services related to migration, implementation, and training.

Organizations relying on platform-based products avoid most local infrastructure costs, including the technical personnel involved.

Larger, complex institutions will continue to require systems librarians and other experts in metadata and operational workflows. These larger institutions may also make use of programmers that work with the system for integration with existing systems or to create tools or extensions to meet specific needs of the organizations.

Locally hosted server-based products

Integrated library systems or other complex applications implemented on local servers incur a variety of costs. Libraries pay software and maintenance fees to the vendor. They may also incur costs related to the support of the technical infrastructure such as local servers, maintenance contracts, data center fees as well as personnel costs for systems administrators or other technical personnel.

Vendor-hosted server-based products

Integrated library systems or other complex applications hosted by the vendor are usually offered through an annual subscription fee, not unlike that for multi-tenant products. Libraries pay a single comprehensive fee which includes all software fees and infrastructure costs.

For the vendor, deployment of server-based products lacks the efficiencies of multi-tenant platforms. A copy of the operating environment must be maintained for each customer site. Virtualization and automated deployment tools decrease the complexity and cost for the vendor. Differences in software versions or other factors make this approach less efficient compared to multi-tenant platforms based on a single codebase for all customers using the product.

Open source multi-tenant platforms

Multi-tenant library services platforms developed and deployed as open source software offer the same efficiencies as proprietary products. These efficiencies become diluted when multiple organizations each deploy separate implementations of the environment. This approach loses some of the advantages of a globally distributed platform with a single codebase.

The costs of using an open source library services platform will vary depending on the implementation scenario. For libraries contracting with a services provider, the cost model may be similar to a proprietary product. The vendor providing hosting and support services will charge an annual comprehensive subscription fee. Additional service costs will likely be needed for migration, implementation, and training.

Many smaller and mid-sized institutions implementing an open source library services platform will rely entirely on the service provider for system support and will not need to have their own programmers or technical personnel.

Larger institutions with complex integration requirements may need local programmers and technical personnel to implement interoperability with other business systems and to create functional extensions via the system APIs. Some institutions may also assign programmers or other personnel to participate in the development of the application itself and related documentation.

Institutions that implement their own instances of an open source platform will incur a broad suite of costs. These costs will include infrastructure fees, such as through cloud service providers like Amazon Web Services as well as a team of technical personnel and functional experts that manage the implementation and to provide support, training, and related activities. Self-hosted institutions gain more control over their use of the software and avoid fees paid to service providers. Since the software itself is open source, the institution also saves on license fees. Self-hosted institutions may also allocate programmers or other technical personnel to participate in the development of the application itself. The calculus of costs for institutions self-hosting a complex business application such as a library services platform includes many factors, making it difficult to predict whether this approach can result in savings or additional costs.

Note: Although FOLIO has been developed as a multi-tenant library services platform, there are many separate implementations. Multiple vendors will stand up their own versions of FOLIO. EBSCO Information Services is the dominant provider of hosting services, and its version is understood to be globally multi-tenant with a single codebase. Index Data has implemented an independent instance of FOLIO for its customers, somewhat different from that of EBSCO Information Services. Several large institutions plan to self-host FOLIO, each with their own selection of code versions and modules. Some may include local customizations.

Platform Evolution

Many of the legacy integrated library systems are becoming increasingly outdated due to being based on technical components now considered obsolete. Their core models of functionality may no longer align well with current library needs. Their technical and functional architecture can evolve to a certain extent, but in many cases it is not feasible to reengineer these products to embody modern expectations.

Library services platforms based on current-day cloud technologies and software development techniques can avoid becoming outdated. Their functionality can be incrementally adjusted, with new features and enhancements deployed periodically, including the replacement of specific functions. New interface designs and workflows can be implemented. More importantly, internal technical components can be replaced as needed to ensure the technical integrity and security of the platform. The replacement of internal infrastructure components can usually be accomplished with minimal operational disruption. Each of the major consumer and social network platforms have deployed large-scale changes in their internal components over time to improve their performance and scalability and to refresh end-user interfaces.

Any technical platform must undergo continuous development to achieve ongoing architectural modernization, to ensure scalability, performance, and security. Functionality must be constantly developed to fill in any gaps in features and to adapt to changed or expanded process workflows as expressed by current and potential customer libraries. The core platform may also provide infrastructure for related products, leveraging technical infrastructure, business logic, and data stores to accelerate development, enabling developers to focus on what is needed to address the new product mission.

Concluding observations

As shown in this report, characterizing the levels of “openness” among products involves many factors. It would be an oversimplification to state that open source products mean a higher level of openness than any proprietary product. From a pragmatic perspective, the availability of APIs and frameworks for in-platform apps represent the most important mechanisms extensibility and interoperability.

The current slate of library services platforms offers differing options for libraries interested in open systems that enable practical capabilities for interoperability with external systems and to extend functionality with customer or community-created tools.

FOLIO: as an open source library services platform provides libraries an opportunity to participate in development and to gain access to the software without the obligation to pay license fees. Commercial services are available from multiple vendors for libraries wanting a fully supported environment. As a completed product though in an earlier phase of its development cycle, functionality through its user interfaces and APIs is less mature but continues to evolve. An extensive developer network collaborates in all aspects of development including the creation of functional specifications, technical development, quality assurance, and creating documentation.

OCLC offers an extensive set of APIs that operate with its WorldShare Management Services platform, WorldCat Discovery Services, and other products and services. WorldShare Management Services is a mature product with over a decade of use in libraries and consortia. Its APIs are well documented, and a sandbox is provided for development and testing. No guest access is provided by default, though customers or potential development partners can request a developer key to activate the APIs. OCLC has cultivated an extensive developer network and provides infrastructure for collaboration and for sharing customer-developed code. OCLC has not announced a framework for customer-created apps that run within the platform.

Ex Libris Alma is a mature product with over a decade of use by libraries and library consortia, including many large-scale implementations. The product offers an extensive suite of APIs which are heavily used by its customers. The company reports that more transactions are conducted on its higher education cloud through APIs than through user interfaces. Ex Libris is the only vendor that has developed a framework for customer or community developed apps that run inside its platform. Ex Libris has cultivated an extensive developer network and provides sophisticated infrastructure to support community development, including a live guest sandbox with guest developer keys that can be used by non-customers in addition to the keys issued to customers and development partners.

Additional resources

Breeding, Marshall. (2020). Ex Libris Introduces Cloud Apps. Smart Libraries Newsletter 40 (9), 3-6.

Breeding, Marshall. (2020). Smarter Libraries through Technology: Community Development. Smart Libraries Newsletter 40 (9), 1-3.

Breeding, Marshall. (2018). Reshaping Academic Library Systems. Smart Libraries Newsletter 38 (1), 1-2.

Breeding, Marshall. (2017). Open Source Library Systems: The Current State of the Art. Library Technology Reports 53 (6).

A Guide to the Cloud, Multi-Tenancy, and The One Codebase to Rule Them All

Breeding, Marshall. (2009). Opening up Library Systems through Web Services and SOA: Hype or Reality?. Library Technology Reports 45 (8) .