Chapter 1. Introduction and Concepts

This issue of Library Technology Reports covers a variety of issues related to the genre of library services platforms. These products represent the latest wave of automation systems for libraries that depart in many ways from those of the previous era and that also carry forward the essential functionality upon which libraries rely for their daily operations. The ensuing discussion and descriptions of library services platforms will reveal capabilities that have been present for decades as well as many characteristics that set them apart as a distinct product category.

This report aims to provide a general understanding of this new category of products and to provide libraries with additional data and perspective as they consider the options available in developing their technology strategies. Library services platforms have not replaced previously established categories wholesale and for all types of libraries. Integrated library systems continue to flourish as seen by ongoing use of existing installations and in new sales. Each type and size of library comes with its own concerns and requirements that it expects to be addressed by its technology products. While library services platforms may be appropriate for a growing set of libraries, any data that demonstrates the types of libraries using any given product can be helpful as libraries ponder their options.

This report does not attempt to make recommendations for the products it covers, but to treat each product in a neutral manner. Libraries making decisions about products should consult with a variety of sources as they work through their procurement process. The report provides general descriptions and presents empirical data related to the numbers and types of libraries that have implemented each product. Sources of data include previously published statistics, figures provided by the vendors of the products, the libraries.org library directory, and the 2014 “Library Automation Perceptions Survey.” While general descriptions of the products are given, the report does not attempt to list or characterize the detailed functionality of the products covered. An understanding of the specific features of each product and its suitability to any given library can be gained only through a more in-depth process than could be captured in a report such as this one. Checklists of functionality can be misleading relative to the actual performance of any given system in its daily operation in a library. Consider the information in this report introductory and preliminary to a more thorough process that would need to be conducted as a library investigates the field of available products.

Libraries.org

www.librarytechnology.org/libraries

The scope of the report includes the major products with a significant presence in North America that embody most of the characteristics of a library services platform, as described in the following section. Products given specific treatment include OCLC WorldShare Management Services, Ex Libris Alma, Sierra from Innovative Interfaces, ProQuest Intota, and Kuali OLE. SirsiDynix BLUEcloud Suite, a hybrid product, is mentioned but not given separate treatment in the product section. This report also does not cover Spydus 9 from Civica since it does not yet have a presence in the United States, but it is a product that warrants consideration in other international regions.

What Is a Library Services Platform?

The term library services platform describes a type of library resource management system with a set of characteristics that differ substantially from the long-standing genre of integrated library system. At this time, there was considerable concern about integrated library systems not necessarily meeting expectations, and it was helpful to consider the new generation of products as a new category that did not have the conceptual and functional baggage of the existing set of products. But the introduction of the term has also introduced some confusion, especially since many products fit some of its characteristics and not others. Above all, as we consider library services platforms, it must be noted that it describes a set of products that each embody a somewhat different set of conceptual, technical, and functional characteristics. While I continue to see library services platform as a helpful term to describe this set of products, the lines of distinction remain blurry.

We refer to any major product that a library uses to manage some set of its collection as a resource management system. This broad category includes library services platforms, integrated library systems, electronic resource management systems, and digital collections management systems, as well as those products that may be used for other categories of specialized materials.

I coined the term library services platform in 2011 to describe a new set of products that were being developed that promised to take a much different approach to library resource management than the incumbent integrated library systems.

I initially proposed the term in my August 2011 Smarter Libraries through Technology column in Smart Libraries Newsletter:

I’m gravitating toward the term “library services platform” for this new software genre. The products are library-specific, they enable the library to perform its services, internally and externally though their built-in functionality, as well as exposing a platform of Web services and other APIs for interoperability and custom development. In a time when long-standing terms like “integrated library system,” or OPAC bring along considerable negative baggage, we need new terms when we talk about what comes next.1

My September 2011 Systems Librarian column in Computers in Libraries further refined the concept:

This new generation of products—more appropriately called something like library services platforms rather than integrated library systems—addresses the fundamental changes that libraries have experienced over the course of the last decade or so toward more engagement with electronic and digital content. In their own distinctive ways, these recently announced or delivered systems aim to break free of the models of automation centered mostly on print materials deeply embodied by the incumbent line of integrated library systems. To make up for functionality absent in their core integrated library systems, many libraries implemented a cluster of ancillary products, such as link resolvers, electronic resource management systems, digital asset management systems, and other repository platforms to manage all their different types of materials. The new products aim to simplify library operations through a more inclusive platform designed to handle all the different forms of content.2

The introduction of the term library services platform was also meant to provide a vendor-neutral product category. As each of these products was being introduced, each vendor posited its own name for its approach. Ex Libris used Unified Resource Management, and OCLC used Web-Scale Management Service. Vendors tend not to use each other’s product categories for new products, so providing a neutral term was needed. The term has since been adopted in both the library and vendor communities.

Historic Perspective: Consolidation of Functionality

The general missions of libraries have remained fairly constant throughout the history of this institution. They develop collections of materials of interest to their communities and provide ways to make those materials available. The types and formats of materials that comprise their collections and how they have been stored, organized, and made available have changed with each era of publishing and content distribution. In each phase of the history of libraries, they have made use of the tools and technologies of the time to facilitate their work.

The history of library technology tracks alongside the prevailing technologies available in the general business and consumer sectors. Methods employed by libraries have constantly evolved. Though we don’t aim to delve too deeply into the history of library automation, some of the tools employed prior to the age of computing include handwritten sequential catalogs, printed catalog volumes, and card catalogs. Computers allowed libraries to manage and provide access to their collections more easily. Early products included computer output microfilm. The early mainframe computers were also put to use to help libraries automate the circulation, cataloging, and acquisitions of their collections. Programs dedicated to individual areas of library operations eventually coalesced into integrated library systems that addressed multiple areas of functionality based on centralized databases. Library-oriented applications have been developed and redeveloped through each of the generations of technology, from mainframes to client/server applications and more recently into those based on cloud computing and web-based technologies. The functionality addressed has likewise morphed over this period, with new products emerging to support the library involvement with electronic and digital materials and in providing ever more effective tools for their management and access.

One theme that has remained constant through the development of library automation systems can be seen in the gradual consolidation of programs and tools that each addresses a given area of the library’s work into more integrated or unified platforms. Each phase of libraries brings new operational tasks that benefit from technology, leading to new products to meet those needs. In subsequent phases, new products emerge that subsume much of the functionality of these multiple applications, resulting in more streamlined and integrated platforms.

The realm of computing technology culminated in the late 1970s with the development of integrated library systems. The individual programs dedicated to individual areas of library operations eventually coalesced into business applications that addressed multiple areas of functionality based on centralized databases. Separate applications for each area of the library were consolidated into the first generation of integrated library systems. The earliest phase of library automation was characterized by specialized systems for each main area of library processing. Gaylord offered its Circulation 100 and CLSI offered LIBS100, which primarily addressed the circulation of books. Innovative Interfaces, Inc., offered its INNOVAQ product, which specialized in materials acquisitions. Libraries at this time could have products from different vendors to automate their operations. Each of these products, and new entrants into the arena, developed into full-fledged integrated library systems.

The ongoing evolution of publishing and content creation continually makes an impact on the types of materials collected by libraries. Libraries have increasingly become more involved with print and digital materials, thus creating the need for new tools and technologies to acquire, manage, and provide access to them.

The first decade of the twenty-first century saw a new phase of fragmentation in library technologies. The integrated library system was well established as the core automation system, adopted in all but the smallest of public and academic libraries in the developed world. As libraries began to acquire electronic resources, new tools were needed for each aspect of the management of and access to those materials.

• Integrated library systems, although comprehensive for the acquisition, management, and access to primarily print materials, saw their role in the overall technology environment of a library diminished for those libraries that shifted their collections acquisitions to primarily electronic and digital resources. See the section “Library Services Platform or Integrated Library System” later in this chapter for more details.
• OpenURL link resolvers emerged in the early 2000s to assist libraries in providing a manageable approach to linking from citations to the full text or other services to make articles available to library users. These products were able to provide context-sensitive linking to the full text on the server of the publisher to which the library subscribes. Hard-coded links used prior to the emergence of link resolvers were unsustainable due to the massive numbers of e-journals and articles to which libraries provide access and in the enormous effort required each time the library changed its subscriptions or when a publisher adjusted its servers.
• Knowledge bases of electronic resources provide a database that describes the content packages to which libraries subscribe. The knowledge base provides current lists of each of the e-journals included in any aggregated content product and the years covered, the syntax needed to link to individual articles, and many other details related to the body of library-oriented electronic content. These knowledge bases support OpenURL link resolvers and other applications that benefit from data related to e-resource holdings. A knowledge base of e-journal holdings describes the totality of the content potentially available to libraries. Link resolvers would include a profile of the library’s subscriptions to inform its ability to provide direct links to items available to a library patron directly or to offer alternative services for those not found within the library’s collection of subscriptions.3
• A–Z listings and other finding aids are often associated with link resolvers and make use of the e-resource knowledge base.
• Electronic resource management systems provide specialized capabilities for acquisition, description, and other operational tasks associated with aggregated content products, e-journals, and other packages of electronic content. These products usually rely on a knowledge base of e-content products to simplify management activities. Electronic resource management systems provide functionality not traditionally included in an integrated library system, such as coding and tracking of license terms, collection of usage statistics, analysis of value and performance of content packages, and other functionality specific to this type of content. Electronic resource management systems include financial management components to manage expenditures relative to established library budgets. They have to handle multiple procurement models, including standard annual subscriptions, open-access selections, purchase of backfile collections, and other scenarios.
• Libraries may also maintain one or more publishing or repository platforms where they store, describe, and manage documents or other content objects on behalf of their institutions. These publishing platforms might include repositories for electronic theses and dissertations or institutional repositories for holding local copies of published scholarly articles, research reports, institutional publications, and other materials. Digital asset management systems or other platforms for managing collections are needed for libraries with digitization initiatives for manuscripts, photographs, or other materials or for managing natively digital content.
• Digital preservation platforms provide additional layers of functionality to a digital asset management environment to ensure the long-term viability of digital materials.

The emergence of library services platforms brings another round of consolidation of functionality that brings together several categories of functionality that had been handled in separate products. The library services platform in general will replace multiple incumbent products, including the integrated library system, any formal or informal products or processes to managing electronic resources, and knowledge bases of e-content resources. These platforms can also address link resolution, though this functionality spans a gray area between resource management and discovery.

Library services platforms should not be considered monolithic self-contained systems that become the only technology product a library will need. We have noted that library services platforms generally do not handle discovery, though many providers will offer a library services platform and a discovery service as an integrated suite. The current products also do not necessarily serve as publishing platforms to replace institutional repository or large-scale digital asset management systems. Some of the products may have basic capabilities, but content publishing has not been a main focus of development for these products.

The broader scope of these products must be taken into consideration relative to their cost. It may not be a fair comparison, for example, to evaluate the cost of a library services platform relative to an integrated library system that addresses a narrower scope of resources. The library services platform may replace three or more incumbent systems, usually the integrated library system, the electronic resource management system, and a link resolver and its knowledge base. When delivered as a web-based service, it also displaces local servers and their associated hardware, software, environmental, and personnel costs. A much larger portion of a library’s technology support infrastructure will be concentrated in a library services platform rather than dispersed among multiple products and processes that may have characterized the incumbent environment.

Definition and Characteristics

A library services platform enables libraries to acquire and manage their collections, spanning multiple formats of content, including at a minimum physical materials and electronic content. These products support multiple procurement processes, including those related to items purchased for permanent ownership, those made available through paid licenses and subscriptions, and those selected from open-access sources. They offer a metadata management environment offering multiple schemas as appropriate for each of the respective material formats, including at a minimum the MARC family of metadata standards and Dublin Core. A library services platform may include an integrated discovery service or support a separately acquired discovery interface by exposing all needed APIs and other interoperability protocols. Library services platforms are offered through a multi-tenant platform, providing all staff and patron functionality though browser-based interfaces. These products provide knowledge bases that represent the body of content extending beyond the library’s specific collection.

Functional Characteristics

Refining this general definition with more detail, some of the characteristics of a library services platform include the following.

Management of Electronic and Print Formats of Materials

This genre of products consolidates the management of print and electronic materials into a single platform, taking advantage of common data stores, task workflows, and other points of efficiency. Archival materials, institutional records, and large-scale digital assets may eventually be subsumed within library services platforms, but are usually still managed in separate systems.

Replacement of Multiple Incumbent Products

As noted above, the implementation of a library services platform in most cases will displace existing technical infrastructure components including the integrated library system and electronic resource management systems. For libraries that have not implemented electronic resource management systems, data and processes managed in local spreadsheets and databases can be more structurally managed through the library services platform.

Extensive Metadata Management

The library services platform supports multiple metadata formats as appropriate for each format, including MARC, Dublin Core, or other XML standards. The need to manage multiple formats of collection materials comes with the need to break outside of the exclusive use of the MARC family of metadata standards. A library services platform will support MARC and non-MARC metadata, either through a normalized internal set of data structures or through a mechanism that natively stores different types of records. New metadata formats based on linked data, especially BIBFRAME, have not yet been operationalized, but they provide an example of new and emerging metadata practices that will need to be adopted by all resource management systems in the relatively near future.

BIBFRAME

http://bibframe.org

Multiple Procurement Workflows

The library services platform supports procurement workflows for purchased, licensed, and open-access materials. One of the limitations of the integrated library system is related to its orientation to procurement processes for direct ownership. As libraries become increasingly involved in the licensing of electronic materials, many aspects of this type of business arrangement did not fit within the structure of the integrated library system. License terms, tracking of individual titles within aggregated packages, and end-user linking mechanisms were usually accomplished in other ways and often by a different set of library personnel. Despite the considerable overlap in some aspects of the process, these separate processes resulted in a fragmented and less operationally efficient operational workflow. Library services platforms integrate the acquisition and management of electronic and print resources into a common platform, data stores, and task workflows. An initial phase of this integration may come with placing an electronic resource management module within the same interface as that for print management, but the full integration of the management of these different categories of materials in a completely integrated set of business processes more completely satisfied the vision of the library services platform.

Knowledge Bases

The library services platform includes knowledge bases and bibliographic service from which local collections are drawn or defined. The model of the integrated library system assumes a reliance on external resources for the metadata involved in collection description and management. The emergence of electronic resources led to the use of knowledge bases provided with the service that functioned as a built-in metadata repository. Libraries using these products did not have to create their own databases of e-resource holdings, but could rely on a knowledge base maintained by the supplier. The local collection was defined by a profile that appropriately filtered the comprehensive knowledge base into the specific resources held by the library. The library services platform expands this knowledge base approach to a wider set of resources. At least some of the library services platforms include a built-in knowledge base for both print and electronic resources. Examples include WorldCat as the global bibliographic resource upon which WorldShare Management Services relies; Alma, which includes a Community Catalog of resources available to all libraries as they define their local collections; and ProQuest Intota, which relies on an expanded knowledge base that was originally created in support of the company’s link resolver and electronic resource management products.

Built-in Collection Analytics

Although integrated library systems usually include a standard set of reporting tools, library services platforms are often able to provide more advanced capabilities for collection analysis and assessment. Those deployed through multi-tenant platforms may be able to not just provide analysis of the library’s local collection independently, but to also use broader data from the platform and its knowledge bases.

Conceptual Organization

The organization of functionality of a library services platform may deviate from the traditional ILS modules (cataloging, online catalog, circulation, acquisitions, serials management, authority control). Fulfillment, for example, may be used to represent the tasks and activities related to the lending of physical materials and the provision of access to electronic resources. Metadata management may be used for describing functions that support MARC-based cataloging, describing digital items in Dublin Core, and managing knowledge base profiles for electronic resources.

Discovery

Library services platforms integrate with a discovery service rather than provide a traditional online catalog. Library services platforms differ in their approach to patron interactions compared to integrated library systems. The online catalog module of the integrated library system provides direct access to the collection and patron-oriented features through internal and proprietary mechanisms. Library services platforms have a more indirect relationship with patron interfaces. Discovery services belong to a separate product genre. For most of the library services platforms, the concept of an online catalog does not apply. Library services platforms expose the APIs that enable a discovery service to provide these services. In some cases, the provider of the library services platform also offers a discovery service. The relationship with discovery services is explored in chapter 3.

Technical Characteristics

Library services platforms have been developed to follow the prevailing concepts of current technology. While the specific architectures and technology components found within each of the products in the category of library services platforms may differ, some general technical characteristics can be expected.

Beyond Client/Server Computing

The current generation of integrated library systems was developed during the era when client/server computing prevailed. This model of distributed computing continues to be seen in existing applications, but only rarely in newly created products. Software applications may continue to be layered into client and server tiers internally, but that architecture is not conspicuous in end-user deployments. Almost any new software-based product created in recent years would be designed to be deployed as web-based service rather than software that has to be installed on either institutional or individual computers. The previous era of client/server computing required the installation of software on a server that provides the basic functionality of the system for that organization, including the business logic and data storage needed to support that organization. Each organization that uses that product would have its own separate installation of the software and independent copies of its own databases. The individual users in the organization that operates the software would also need to have software installed on their own computers. These client applications provide the user interface, manage communications with the server component, and may perform additional tasks such as checking for the validity or integrity of data. This client/server architecture provided advantages over the earlier era of mainframe base computing, but it required significant administrative overhead in the need to install and maintain software components.

Multi-Tenant Platforms

A multi-tenant application serves all of the organizations or individuals using it through a single instance. The service is delivered through a single codebase, and all users of the application operate from the same version of the underlying software. Data structures are organized to segregate data that pertains to each institutional or individual user or to allow selected data stores to be shared globally. These multi-tenant systems are generally distributed globally, with data centers in different continents. Users in one region access the system from the nearest data center, with the ability to shift access to another should a failure occur. Most modern services rely on multi-tenant deployment, including business-oriented products such as Salesforce.com, e-commerce environments like Amazon.com, social networks such as Facebook, or messaging utilities like Gmail. Multi-tenant applications can support massively large-scale services.

This style of computing is not new to the library arena. Many well-established library-oriented products are offered in through multi-tenant platforms:

• WorldCat.org
• most electronic content products
• discovery services, such as Summon, EBSCO Discovery Service, and Primo Central
• some library automation products:
  • Apollo from Biblionix
  • the 360 suite from ProQuest
  • EBSCO A–Z, LinkSource, etc.
• library services platforms offered as multi-tenant services, including Alma, OCLC WorldShare Management Services, and ProQuest Intota

A variety of benefits are gained through multi-tenant applications in the library arena. Vendors that offer a product based on this architecture operate a single instance of the codebase that is able to take advantage of a large pool of hardware resources and software components. Adding new customers increases resource consumption by only small increments. Database tunings, configurations, software patches, and other routine system maintenance activities can be done once and applied globally. For companies serving a large customer base, maintaining a single large multi-tenant platform can be accomplished with fewer technical personnel compared to having to install and maintain thousands of separate institutional instances. Patches applied to the software to fix bugs take effect for all customers at once, compared to having to perform upgrades to hundreds or thousands of separate servers.

Applications can evolve gracefully in a multi-tenant environment. New features or fixes to existing functionality can be added to the global instance on a frequent schedule since this model does not impose software installation tasks on end users. Some needed enhancements, such as those needed to address a security issue, may be deployed entirely transparently to end users. Significant changes in the behavior of the system might be offered initially as optional features that can be tested by end users before becoming activated in the production platform.

Libraries benefit from multi-tenant platforms as well. Given that all the technical administration is executed by the vendor, the burden to the library is very light. In most cases the library will not need to allocate technical personnel for the administration related to their use of the system. In larger libraries, there may be higher-level tasks that require the attention of a systems librarian or functional expert related to institutional configuration issues, data loading, or interactions with other local systems. Smaller libraries will operate these products with very little local intervention.

From the library perspective any form of hosting can reduce the need for managing local equipment and its associated involvement of technical personnel. The difference between the vendor hosting a server-oriented system and a multi-tenant platform is more subtle from the library’s perspective. Either version shifts responsibility for the technical infrastructure from the local institution to the vendor.

• Multi-tenant systems may offer built-in content resources, such as knowledge bases and bibliographic data sources.
• Multi-tenant systems usually offer a higher-level, more abstract configuration process.
• Server-oriented systems may perform well in implementations with very high transaction loads. The hardware can be scaled and software optimized to handle peak periods. Most large urban libraries, for example, continue to rely on locally hosted server-oriented integrated library systems.

For many libraries the practical differences between a vendor-hosted server-oriented system (ASP) and a multi-tenant platform can be subtle. Whether the technical architecture of a product is multi-tenant or relies on a separate institutional instance may have a relatively small impact on how the software functions for a library. The difference between a system housed and managed by the institution versus either of the hosted models (SaaS or ASP) makes substantial operational impact.

Web-Based Interfaces

Library services platforms provide web-based interfaces, requiring no local software in servers or staff workstations. The integrated library system emerged during the client/server phase of technology. These products were based on data stores and business logic residing on servers housed in the data center of the library and software installed on library staff workstations that provided a graphical user interface that performed some processing, usually related to error checking, communications optimization, and presentation-oriented tasks to off-load processing from the central servers. Library services platforms, in contrast, provide all functionality to library personnel via interfaces presented through their web browsers. The data stores and business logic reside on a multi-tenant platform hosted by the vendor, eliminating the requirement for a local server, or an institutional server hosted by the vendor or other co-location provider. Delivering all interfaces via web browsers eliminates the often substantial overhead involved in the installation and upgrades of staff workstation clients and institutional server software, hardware, and operating systems.

Services-Oriented Architecture

The current preferred framework for software development is based on the creation of high-level functionality composed of many reusable lower-level granules of functionality called services. This services-oriented approach enables efficient and flexible software development since each small task need only be coded once. Low-level services can be organized into middleware that provides a generalized set of resources for higher-level business applications. Domain-specific functionality can be developed on top of the middleware layer to focus development on unique work rather than tasks common to most software applications.

APIs Exposed for Extensibility and Interoperability

In addition to the interfaces provided for staff to use via their web browsers, library services platforms also provide application programming interfaces. These interfaces are not consumed by humans, but rather listen to requests from external systems or programs and provide appropriate responses. APIs can enable advanced reporting capabilities by providing data managed within the system to external applications that will calculate statistics, perform analysis, and control formatting. APIs can also be used to programmatically update data, such as global changes or other tasks that may not be built into the staff interfaces. APIs that perform updates are generally carefully secured and limited to authorized personnel or processes to avoid accidental changes or data corruption. In the same way that all of the functionality of the staff interface must be well documented, the developer of the system must also provide detailed documentation of each of the APIs exposed.

Interoperability

Library services platforms interoperate with external applications such as ERP (enterprise resource planning), financial systems, student account management, and learning management systems via APIs rather than batch load of records. For many institutions, the library and its resource management systems represent only one component of the technical infrastructure that supports the enterprise. Library systems often consume data managed by another system, such as receiving patron records from a university’s student management and human resource management systems. The financial data and transactions managed by the library’s acquisitions processes often need to be transmitted into the financial management of its higher-level institution. Ideally, these data transfer and synchronization tasks can be accomplished through the APIs of the respective systems. At a minimum, data files can be extracted via APIs that can then be imported or loaded into an external system.

Subscription Pricing

Providers generally offer library services platforms through a subscription-based business model. For installed software, for large applications such as an integrated library system, the business model was based on an initial amount paid for the initial license, plus additional annual charges for ongoing maintenance and support. Software-as-a-service is usually offered through an annual subscription fee set according to the size and complexity of the organization. The first year might include some additional costs associated with migration and set-up. The fixed cost of the subscription displaces a variety of direct and indirect costs associated with installed software applications, including hardware, operating systems, and data center environment, as well as technical personnel. The annual subscription cost for a SaaS product is generally higher than the maintenance fees associated with a locally hosted application, but the total costs should generally be comparable when all expense categories are calculated.

A Maturing Set of Products

Library services platforms can no longer be considered “next-generation systems,” but rather by now well-established products that have seen implementations in hundreds of libraries. The conceptual design of the products, which later become known as library services platforms, began in 2009. Multiple organizations entered an intense phase of product development that culminated with some implementations as early as December 2010. By the end of 2014, almost 1,000 libraries have implemented one of the available library services platforms. Many others having signed contracts for a library services platform and are in the installation process.

Most Products Well into the Adoption Cycle

The completeness of development and the maturity of each of the products that can be considered within this genre vary (see table 1.1). Ex Libris Alma and OCLC’s WorldShare Management Services have seen production use for more than two years and have matured considerably beyond their initial release. Kuali OLE, though in production in two libraries, currently addresses only print functionality, and the next version, which also manages electronic resources, is expected to be ready for implementation in early 2015. ProQuest Intota is available in what the company characterizes as a foundation release that focuses on the management of electronic resources and does not yet include the functionality for print. The Sierra Services Platform from Innovative Interfaces embodies characteristics of both a library services platform and an integrated library system. Since its release in mid-2012, over 495 libraries have placed Sierra into production, reflecting a strong level of acceptance of this product. We’ll look at each of these products in more detail in chapter 4.

A key component of a technology strategy relates to assessing the level of risk associated with any given product or category of products. While some libraries see advantages in taking calculated risks by participating as development partners, beta testers, or early implementers of a product, the vast majority of libraries must take a more cautious approach.

Libraries can look to their peers to help them assess risk. Libraries in the first wave of testing and adoption assume the highest level of risk. The level of risk declines as a product builds an installed base. Libraries can solicit information from libraries that have previously implemented the product to learn more about how it has performed and whether it has the features and capabilities expected. Reliance on recommendations from reference sites is a long-standing component of the research performed by a library as it considers strategic technology products.

From Development to Implementation Phase

Library services platforms have been in the deployment phase for several years, providing an increasing body of evidence regarding their efficacy. Information gathered from libraries that gave gained firsthand experience with these products can boost confidence in whether it performs as advertised or if it fails to fulfill expectations. Such assessment data can apply to a new product genre or concept, to the individual products that constitute that genre, and to a product’s use in specific types of libraries.

The maturity of a product can be considered in terms of a series of benchmarks, including these:

• Completion of initial development. Has the development of the initial version of the product been completed? The initial version may not provide every feature anticipated, but to be considered complete, it should address the full range of functionality at some level.
• Early production phase. At least a small number of libraries have implemented the product and are using it as their daily operational system and have been able to decommission their incumbent systems.
• Mass deployment. The product is considered a routine offering, with dozens or hundreds of libraries using it in production.

Technology products seem to never achieve a final point of development when they might be considered “finished.” Even integrated library systems, which have been on the market for decades, continue to see enhancements to provide new features and capabilities, to fix bugs, and to address security issues. New products, such as library services platforms, will usually see intense ongoing development following the initial version. This ongoing development may result in new features, increased stability, or faster performance, which will be deployed incrementally. Products deployed through multi-tenant platforms can be enhanced gradually, rather than in the large-step version releases of the previous generation.

Sources to Assess Implementation Patterns and Acceptance

A variety of resources are available that help libraries assess the maturity of a product in terms of its development cycle and implementation patterns.

• “Library Systems Report,” published annually by American Libraries, includes sales statistics and other data provided by vendors for each of their major products. This report covers integrated library systems, library services platforms, discovery services, and other strategic library products. The number of sales and installations reported provide an important measure of the acceptance and maturity of the product. This report continues the “Automation Marketplace” published in Library Journal that I authored between 2002 and 2012.
• Implementation data from libraries.org. Library Technology Guides includes the libraries.org directory, which documents the strategic automation products used in libraries in addition to other details. The data in libraries.org cannot be considered comprehensive, but it is the most complete resource for this type of data. It provides strong coverage of public and academic libraries in North America and Europe. Particular attention has been given to documenting the libraries that have been involved with selecting and subsequently implementing library services platforms. Statistics and charts from libraries.org are used in this report to illustrate the adoption patterns of library services platforms.
• “Library Automation Perceptions Survey.” Conducted through Library Technology Guides, the “Library Automation Perceptions Survey” has been conducted annually since 2007. This survey is completed by libraries to rate their impressions of products in a variety of categories. The 2014 Perceptions Survey collected data from October 22, 2014, through January 15, 2015. The 2014 edition of the perceptions survey was not published by the time of the completion of this report, but preliminary results have been included for the library services platforms we cover.

Library Technology Guides

www.librarytechnology.org

Uneven Time Line among Products

The current state of the development of library services platforms reflects considerable unevenness. Conceptually, this model of resource management has been in play since around 2009. In that year OCLC, the Kuali OLE project, and Ex Libris had begun exploring these concepts with libraries and began general product design. Concerted development took place on multiple products from 2010 through 2012. OCLC was the first of this group to achieve a move into the implementation phase, with Craven-Pamlico-Carteret Regional Library System, a small public library consortium, placing WorldShare Management Services into production in November 2010. Boston College became the first library to implement Ex Libris Alma in July 2012. Innovative Interfaces announced Sierra in April 2011, and it was implemented in Hillsdale College a year later in April 2012. Following three phases of development, Kuali OLE Version 1.5 was implemented in Lehigh University in August 2014. ProQuest announced its intention to build a library services platform, later branded as Intota, in June 2011, considerably later than OCLC, Ex Libris, or Kuali OLE. No libraries have yet put the full version of Intota into production, through several have implemented a preliminary package that includes Summon, 360 Link, Intota Assessment, and a version of Intota for electronic resource management. This version does not yet allow the libraries to decommission their integrated library system.

Development Strategies: Greenfield versus Brownfield

How quickly an organization can develop an incredibly complex software application such as a library services platform relates to many factors. Organizations with a large development capacity will have an advantage. The number of personnel allocated for software development provides one metric. Organizations with a development team’s programming infrastructure already in place will naturally have an advantage over those that must recruit, train, and establish new processes and procedures. Each of the organizations involved in the development of library services platforms is relatively large with personnel allocated to product design, software architecture, programming, quality assurance, and testing.

Another interesting aspect of the library services platforms concerns the extent to which each is an entirely new product and which have built upon existing components. One can use concepts in the software development realm borrowed from other kinds of projects. Software projects can be considered “greenfield” or “brownfield” depending on whether they incorporate previous development efforts. Definitions of these terms as applied to software development are given in Wikipedia:

• “Brownfield development is a term commonly used in the IT industry to describe problem spaces needing the development and deployment of new software systems in the immediate presence of existing (legacy) software applications/systems.”4
• “A greenfield is a project that lacks any constraints imposed by prior work. The analogy is to that of construction on greenfield land where there is no need to work within the constraints of existing buildings or infrastructure.”5

In the library services arena, a distinct trade-off can be seen in the greenfield versus brownfield approaches. A brownfield project has the potential to shorten the development phase, but it can also moderate the extent to which the product is able to thoroughly revise functionality and be expressed through new technology architectures and infrastructure components. The offerings in the genre of library services platform exhibit varying development strategies.

OCLC WorldShare Management Services took the greenfield model. An entirely new technology platform was created for the service. It is not known to have borrowed programming code or components from any of the integrated library systems that the company has acquired (Amlib, OLIB, LBS, CBS, Sisis Sunrise, and BOND Bibliotheca). The WorldShare Platform does leverage the content of the massive WorldCat bibliographic service. It also uses the existing OCLC Connexion as its initial cataloging interface as it works toward a full cataloging module based on the WorldShare Platform. OCLC also positions the existing WorldCat Local service as the discovery interface for WorldShare Management Services. In 2014 OCLC launched WorldCat Discovery Service on a new platform to eventually replace WorldCat Local and its FirstSearch service.6

The development of Alma by Ex Libris can be seen as a greenfield project. Alma was developed on an entirely new codebase apart from its Voyager and Aleph integrated library systems, its Verde electronic resource management system, and its SFX link resolver. The company had two existing integrated library systems that were both quite successful, with ongoing use in some of the world’s largest and most prestigious libraries. Voyager was developed by Endeavor Information Systems, seeing its first production use at Michigan Technological University in December 1995. Aleph, originally developed in the 1980s, had evolved through multiple cycles of technology, but was not considered appropriate as the basis for the company’s new strategic platform. The content of the Alma knowledge base incorporated and extended the one created for SFX, but the platform and code are new. Ex Libris packages Primo and Primo Central as the discovery service for Alma. Primo was itself a greenfield service, created in 2006, that has been enhanced and extended over its product history.

The Kuali OLE project can be considered a hybrid approach. The codebase for the domain-specific functionality of Kuali OLE is entirely new. The project opted to make use of software components, including the Kuali Rice middleware and Kuali Financial System. Kuali Rice provides a modern services-oriented foundation, but it was not created to support multi-tenant services. Kuali Financial System is in the process of being redeveloped by the new KualiCo organization.

ProQuest has taken a strategy for its new Intota library services platform that leverages its existing products in addition to the development of an entirely new codebase. ProQuest, continuing the products of Serials Solutions, entered the library software development arena recently enough that all of its products have always been developed to be deployed on multi-tenant web-based platforms. So while Intota builds on some existing products, they do not present some of the same considerations as those that other organizations may face relative to products that were created in previous decades based on fundamental computer architectures that have long since fallen out of favor. ProQuest has released an initial Intota package that includes the well-established Summon discovery service, 360 Link, Intota Assessment, and a new Intota electronic resource management module. The ERM component has been deployed on a new platform but carries forward functionality from 360 Core and 360 Resource Manager.

Innovative Interfaces was able to leverage a significant portion of the Millennium codebase in the development of Sierra. Throughout its corporate history, Innovative has based its development strategy on building on established functionality. In creating Sierra, Innovative preserved the layer of the Millennium codebase that supports the business logic and functionality, surrounded by new technology for database management, a layer that exposes the functionality through the services-oriented architecture, and a new set of Java-based staff clients. As can be seen in table 1.2, this brownfield approach enabled the creation of Sierra through a much shorter development phase than those that followed the greenfield model. Only a year transpired from the initial announcement of Sierra in April 2011 until Hillside College placed the software into production in April 2012.

SirsiDynix has taken a hybrid approach. Its BLUEcloud suite can be considered a library services platform since it embodies many of the characteristics of the genre. It is deployed through a multi-tenant web-based platform, manages electronic and print resources, and delivers its functionality through browser-based interfaces. At this point in its development, however, the BLUEcloud suite relies on the implementation of one of the SirsiDynix integrated library systems, Symphony or Horizon.

The development time line of the library services platforms reflects, as expected, a longer period of development for the products that are developed through the greenfield model. Ex Libris was able to create the initial version of Alma in around thirty-six months from the time that its intention to develop the product was announced. The initial production of Kuali OLE came just under fifty months following the beginning of its initial planning project, with more time and work underway until the full version that manages electronic resources has been completed and implemented. The brownfield model allowed Innovative to install Sierra only twelve months following its initial announcement. OCLC placed its WorldShare Management Services into production in its first site after twenty months of development, comparatively rapid for a greenfield project. It must also be considered that this first site, Craven-Pamlico-Carteret Regional Library System, implemented a very early version of the system due to a major failure of its incumbent system. OCLC made the general release of WorldShare Management Services in July 2011, still reflecting an aggressive twenty-six month development cycle. These observations generally show that those projects that are able to take advantage of existing components come to completion in shorter time frame than those that take an entirely fresh start. More important, it shows the enormous investment of resources required to develop a library services platform.

While Kuali OLE was implemented by the end of 2014 in two libraries, these libraries have not yet implemented the components still under development for managing electronic resources. A version of ProQuest Intota has been implemented that manages electronic resources, but not print collections.

Given the uneven state of development, libraries may question whether they should move forward with the consideration of new systems or wait until more systems have become more complete and have seen implementation. One line of reasoning might suggest that a library should wait until all of the products have been completed, reached a certain state of maturity, and seen production implementations. Others might argue that there are at least some products in the genre that are finished, at least in their initial versions, and have seen hundreds of production implementations. Libraries especially interested in open source software may find it worthwhile to wait to observe the progress of Kuali OLE, especially regarding the anticipated capabilities to also manage electronic resources. Libraries with strong ties to ProQuest may want to hold out for the completion of the full version of Intota. ProQuest has put together an interim package of products that allows a library to begin taking advantage of its capabilities for everything but management of the print collection.

The number of offerings in the genre of library services platforms remains relatively narrow. Compared to the number of integrated library systems that have been developed over the history of library automation, this number seems uncomfortably small. We have also seen an often painful process of product consolidation that has taken place through the mergers and acquisitions of the last decade or two. It is not likely that the genre of library services platforms will expand in the near future. Each of the current products is produced by quite strong organizations, providing a reasonable level of confidence that each of these products will endure and reach ever higher levels of maturity and adoption.

Library Services Platform or Integrated Library System

Despite the emergence of the genre of library services platforms, integrated library systems remain a viable option for many libraries. The integrated library system has been the cornerstone of library automation since the mid-1970s and will continue into the future. These two products will continue to coexist for the foreseeable future.

The advent of library services platforms has split the library resource management arena into two threads of development. These two categories cannot, however, be considered as entirely distinct. There are considerable areas of overlap, and some of the directions of development underway in the integrated library system arena may bring these two categories to increasing levels of overlap in the future.

There is already considerable movement among the integrated library systems to shift to all browser-based interfaces, to offer online catalogs with increasing characteristics of discovery interfaces, and to manage multiple types of materials.

Significant development has taken place among the integrated library systems widely used in public libraries to support integrated management and lending of e-books. This integration includes staff-oriented tools to more easily manage the acquisition of new titles from the major e-book providers, but to also conduct the lending and the provision of the e-book to library patrons through the interface of the library’s catalog or discovery interface. These advancements have been seen more in the integrated library systems oriented to public libraries, such as Polaris, Library.Solution, and Apollo. E-book integration has been a strategic emphasis of BiblioCommons.

Another configuration takes a hybrid approach to the integrated library system and the library services platform. The SirsiDynix BLUEcloud includes a suite of applications that fall well within the definition of library services platform. Its components including eResource Central, the BookMyne mobile platform, and the functional modules such as BLUEcloud Circulation and BLUEcloud Cataloging—all reside on a web-native multi-tenant platform. These products do not operate entirely independently, but rely on an implementation of one of SirsiDynix’s integrated library systems, either Symphony or Horizon. SirsiDynix has developed a set of APIs for Symphony and Horizon, called Web Services, that expose the APIs needed to participate in the BLUEcloud environment as well as interoperate with other external scripts or applications.7

One of the key issues covered in this issue of Library Technology Reports concerns providing guidance for when a library should consider selecting a library services platform or an integrated library system as it moves forward in its technology strategies. These products have considerable overlap among these two product genres.

The November 2013 issue of Smart Libraries Newsletter addressed some of the considerations that apply between integrated library systems and library services platforms. That article suggested that at least some of the integrated library systems were evolving into a more progressive set of characteristics that embody increasing similarities to library services platforms. Table 1.3 shows an updated version of the matrix of considerations highlighting this evolutionary track of development.

Some degree of affinity can be seen between type of library and the category of resource management system adopted.

Library services platforms currently see higher levels of adoption by academic libraries than other types. Academic libraries face a major operational challenge in managing collections of predominantly electronic resources with the ongoing need to maintain their print collections. The fundamental tenet of library services platforms to provide comprehensive resource management spanning content format types directly addresses this need.

Public libraries continue to see vigorous circulation of their physical collections, supplemented by an increasing portion of lending of e-books and other digital materials. Integrated library systems, especially with the e-book lending integration tools now available, continue to serve public libraries well.

School libraries have quite specialized needs, including the need to manage relatively small collections of print books with special attention to selections by reading level. These libraries also offer access to electronic resources, but in somewhat different ways than university and college libraries dealing primarily with issues relating to age-appropriate resources. School libraries primarily make use of specialized integrated library systems and discovery tools from companies such as Follett, Book Systems, Alexandria, and others.

Table 1.4 provides data describing the types of libraries that have implemented each of the products. The counts represent the library organizations that are known to have selected each product as recorded in the libraries.org database. As with other data taken based on libraries.org, caveats apply. Numbers shown were taken at the end of 2014. While this is a group of products very closely tracked, some implementations are not made public, so in some cases numbers may be somewhat lower than total reported by vendors. Library counts represent a very rough measure. Some libraries may include multiple branches or facilities, and there is substantial variation in the collection size and other metrics of each library.

Table 1.5 shows the distribution of implementations according to the collection size of the library. It illustrates a pattern that, currently, higher proportions of large libraries have implemented Alma with WorldShare, and Sierra is skewed more toward medium-sized libraries. These figures also show that the number of installations is much larger than the number of libraries represented, illustrating that many have implemented these products via consortial arrangements.

Support for Library Consortia

From the earliest phase of the history of library automation, organizations have worked together to share systems to lower costs and to expand the pool of resources available to the users. So while sharing systems among the members of a consortium is not new, recent years have seen many new large-scale projects. Notable examples include these:

• Illinois Heartland Library System (427 libraries) has consolidated the systems of four previous regional library systems into a single implementation of Polaris.
• The approximately 100 public libraries of Northern Ireland have implemented SirsiDynix Symphony as they consolidated four previous consortia.
• All of the public libraries in the Republic of Ireland announced their selection of Sierra to serve all of the 32 public library services that include around 170 individual branches, consolidating the individual incumbent implementations.
• The public libraries of the state of South Australia have recently completed the implementation of a state-wide automation system using SirsiDynix Symphony, consolidating many previously independent integrated library system implementations.

There have also been some high-profile projects that provide shared technology infrastructure to large groups of academic libraries through shared instances of library services platforms.

• The Orbis Cascade Alliance completed the implementation of its 37 academic library members on January 7, 2015. These libraries had previously worked together as a consortium to share resources using separate integrated library systems and resource-sharing technology. The consortium originally used Innovative’s INN-reach to facilitate resource-sharing requests and routing, changing to WorldCat Navigator in 2008. In October 2012, the Alliance announced its selection of Ex Libris Alma as a single shared automation system for all of its members.
• Following a long planning and procurement process, Wales Higher Education Libraries Forum (WHELF), a consortium of the national library and the major academic libraries in Wales, announced its selection of Alma as the basis of its shared library management strategy.
• The BIBSYS consortium of 105 members that includes the National Library of Norway and the major academic and research libraries, selected Ex Libris Alma in December 2013. Implementation is underway, with an anticipated completion date in late 2015. BIBSYS had previously developed its own system to serve its members.
• The LIBROS consortium of 16 academic institutions in the state of New Mexico announced its selection of OCLC’s WorldShare Management Services in January 2014. By late December 2014, all of the libraries had completed their migrations.
• The Private Academic Library Network of Indiana (PALNI), a consortium of 23 academic libraries, has implemented WorldShare Management Services.
• Cooperating Libraries in Consortium, a consortium of the academic libraries of eight small colleges and universities, has selected ProQuest Intota and has implemented Summon and the foundation release while continuing to operate its Millennium integrated library system.

Other projects known to be investigating or in the procurement process for a shared resource management environment include these:

• VALID, a group of academic institutions in the state of New Jersey. Representatives of this group have been involved in the Kuali OLE project, working toward the possibility of a shared consortial implementation. No specific timetable has been announced.
• The 40 publicly funded universities and community colleges in the state of Florida are in the process of setting a new strategy for a shared automation system. Florida has a history of shared automation systems, with the community colleges and universities each operating state-wide systems. Currently the community colleges share a single implementation of Ex Libris Aleph, while each of the universities uses separate instances of Aleph, with a shared discovery interface. Consideration is now underway for a system to be shared among both groups. An “Invitation to Negotiate Next Generation Integrated Library System” was issued on December 15, 2014, by the Complete Florida Plus Program, the recently established organization with a portfolio that includes responsibility for library automation.8

Notes

1. Marshall Breeding, “Smarter Libraries through Technology: The Beginning of the End of the ILS in Academic Libraries,” Smart Libraries Newsletter 31, no. 8 (August 2011): 1–2, accessed May 6, 2015, http://journals.ala.org/sln/issue/viewIssue/302/64.
2. Marshall Breeding, “A Cloudy Forecast for Libraries,” Computers in Libraries 31, no. 7 (September 2011): 32–35.
3. Marshall Breeding, “E-resource Knowledge Bases and Link Resolvers: An Assessment of the Current Products and Emerging Trends,” Insights: The UKSG Journal 25, no. 2 (2012): 173–82.
4. Wikipedia, s.v. “Brownfield (Software Development),” last modified December 2, 2014, http://en.wikipedia.org/wiki/Brownfield_%28software_development%29.
5. Wikipedia, s.v. “Greenfield Project,” last modified January 3, 2015, http://en.wikipedia.org/wiki/Greenfield_project.
6. See Marshall Breeding, “OCLC Announces WorldCat Discovery Service,” Smart Libraries Newsletter 34, no. 3 (2014): 6–7, accessed May 6, 2015, http://journals.ala.org/sln/issue/view/271.
7. Marshall Breeding, “Smarter Libraries through Technology: The Roles of Integrated Library Systems and Library Services Platforms,” Smart Libraries Newsletter 33, no. 3 (2013): 1–4, accessed May 6, 2015, http://journals.ala.org/sln/issue/view/283.
8. See http://uwf.edu/media/university-of-west-florida/offices/procurement/bids/14itn-04aj/14ITN-04AJ.pdf.