CCS Architecture Analysis - Spring 2016

Owned by Christopher Holly
Last updated: Apr 21, 2017

A consortium of 24 public libraries, Cooperative Computer Services (CCS) started its ILS needs analysis in March 2016. The goals of the Needs Analysis Project included: create needs assessment of CCS Libraries, communicate these needs among member library leadership and staff, engage directors in the process to help foster our collective vision. The Project Team consisted of 48 library staff who serve a variety of different roles within the CCS member libraries. These people worked together in project-specific teams each led by a library Director.  These teams looked at different architectures, products, and processes in order to hone in on the true needs of the cooperative.

These are the variations that the different project teams looked at:

  1. a single, shared instance of the ILS software that is managed by the ILS company itself (no consortial office like CCS is used to manage the software).
  2. A single, shared instance of the ILS software this managed by a consortial office separate from the ILS company.
  3. Clusters of libraries on shared and separate instances of the ILS software (i.e. multi-instance setup) tied together with a resources sharing software.  Some libraries may prefer to still share an ILS (single instance) but other libraries wish to be on their separate ILS systems.  All in all, because multiple ILS systems are being used, this is a multi-instance system.  You could even say it’s a hybrid because some libraries are sharing one ILS (single instance) and others are on a separate ILS system (mult-instance).
  4. All separate, stand-alone systems (one ILS per library) that are connected via a resources sharing software.  This is also multi-instance (like number 3), but unlike number 3, each library is completely separate. 

Numbers 1 and 2 reflect single instance systems and numbers 3 and 4 reflect multi-instance systems.

Based on feedback from the Project Teams and from a survey of the CCS member library directors, the following autonomy needs were raised.  Please note that some of these are related to CCS policies or processes, while others are related to the technical system itself.  They are grouped accordingly to help identify whether a different architecture type would address these issues.

 

PROCESS:

  • Time it can take CCS to implement a new service, while taking into consideration the system impact on other libraries.
  • Time-consuming upgrade process. 
  • Perceived inability to work directly with ILS vendor when needed.
  • CCS intervention needed for some setup needs. 

 

POLICY:

  • Length of time to reach a decision. 
  • Ability to experiment without it affecting other libraries, e.g. autorenewal or fines free. 
  • Flexibility in sourcing bibliographic records and in staffing for cataloging. 
  • Stingy protectionism among libraries.
  • Get roped into policy decision against one’s will, e.g. system holds.

 

TECHNOLOGY:

  • Provide clear, simple access to e-resources (like Hoopla or Lynda) without confusion of who owns which resources. 
  • Too large to be able to use Item Group Editor.  (SirsiDynix only)

 

The above issues are primarily policy and procedure related, not technical limitations.  In fact, given how ILS technology has evolved in the past 15 years with greater means of API use with 3rd party products, easier means for rolling out updates, and the ability to support a different Discovery layer per library, moving to a multi-instance architecture would not resolve many of these needs and merely complicate things for patrons.  If we were to revisit how CCS approaches things like access to the API’s and the ability for each library to work with its own Discovery layer, then some of these issues would be resolved.  This is especially so when weighed against the patron functionality and additional staffing resources needed to support a multi-instance architecture. 

It is important to keep in mind that even with a multi-instance setup with resource sharing software like INN-Reach or Relais, there would still need to be shared policies for how items circulate among member libraries.

In summary, these are primarily issues that need to be dealt with at a consortial policy level.  What does it mean to compromise, and what compromises are better for our patrons?

 

Conclusions from the Analyses of the Project Teams:

The unanimous conclusion from all of the teams was that it makes most sense to remain with a single instance architecture.  The pro’s and con’s of the architectural options are spelled out below.

 

Shared Single Instance

Pros: 

  • Shared patron database for ease of intra-CCS RBP’s
  • Ease (1 click) of expanding search from one member library to all CCS libraries
  • Option for comparative reporting if agree on codes
  • Ability to share bib and authority records and hence find cataloging/tech services efficiencies
  • Cheaper cost than the multi-instance model with resource sharing software
  • Can setup separate Discovery layer per library
  • Can setup access to API’s per library
  • Circulation tables are designed to handle many of the complicated needs for consortia

Cons: 

  • Time spent on creating shared policies and procedures
  • Question over how vendors will solve the issue of handling different e-records among consortia members  (possibly resolved with separate Discovery layers per member institution)

 

Multi-Instance Model

Pros:  

  • Have the flexibility to make changes to the system when you want and as needed (within reason given need to agree on policies for resource sharing software)
  • Access to the system when you want to do what you want (but need appropriate staffing)
  • Can leave e-records out of the shared catalog, so those would only display in your local catalog

Cons: 

  • Very few reference sites (INN-Reach still new with Polaris and Relais still new with SirsiDynix)
  • No shared patron database
  • Deduping algorithm between multiple bib-databases can still result in duplicate entries displaying in some cases (not as clean as a single, shared bib database)
  • Still need to agree on resource sharing policies
  • Patrons need to go to two different areas to see what is checked out at home library versus other CCS libraries
  • Each library setup in its own instance must handle all of the bib and authority record loading
  • Does not create an easier way to have comparative reporting
  • More clicks for a patron to get results from the larger pool.
  • Costlier to acquire and maintain multi-instances with resource sharing software than single instance