Shared System Options

Introduction

This report works on the scenario that each institution will either look to procure a next generation library system as their strategic planning & budgeting dictates, or in response to end of life or their current systems.

What needs to be considered from this project’s perspective is what are the benefits that would make a shared service or set of shared services for Scotland a compelling and cost-effective way forward.

The prospect of establishing a model for shared service across Scotland potentially puts a different spin on some of the standard procurement considerations, and maybe would allow us to share the load a bit more in terms of sharing technical expertise and brainpower. But it would also raise new challenges and force some issues of governance, ownership, and responsibility.

If we consider some of the typical issues to consider for the type of IT services on which traditional library management systems are based…

  • Procurement – will the cost of the system exceed EU thresholds?
  • Fitness for Purpose – will the system meet OUR institution’s essential requirements?
  • Fitness for Use – will the system be performant, and reliable, to the levels we will accept?
  • Relationship management – can we negotiate a service level agreement, or are we presented with a one way set of terms and conditions?
  • Infrastructure – can currently available infrastructure be used, or is additional processing and storage capacity needed?
  • What are the capital and recurrent costs of locally managed hardware, and associated facilities management (or the cost of paying a 3rd party to host and manage a platform)?
  • Systems Integration – have we got local expertise needed to integrate with other library and corporate systems, and if not, can we grow it ?
  • Startup and Recurrent Costs – Direct and Indirect costs of Hardware, Software, Staff, Accommodation, 3rd Parties, etc?
  • Business continuity – what needs to be in place to ensure continuity, and what disaster recovery options are budgeted for?
  • Security – what measures are in place to ensure our data / infrastructure / facilities are secure?
  • Data Protection – if data is held by a vendor, what measures are in place to ensure we are in compliance with UK legislation?
  • Financial Health of the vendor / organisation?
  • Support – are we (or can we be) geared up to support the service locally, or do we need supplier / 3rd party support?
  • Customer base, User groups, etc?

The prospect of a regional or national shared service changes the game / perspective on almost all of the above, in terms of scale and potentially complexity; some of the issues are non technical but will come down to local / institutional policy, or the political will and desire to find a common solution , as what is considered the highest priority for one institution’s procurement may not initially fit with everyone else’s thinking.

Characteristics of Next Generation Library Management Systems

The last few years have seen search and discovery functionality increasingly separated from the traditional LMS, in a response to the expectations of users growing up with Google. This, and the dissatisfaction with the widening gap between LMS core functionality and what is now required to manage digital collections, led to the development of next generation library systems or what have also been termed Library Services Platforms.

As Carl Grant helpfully explains in his recent article in Information Standards Quarterly, there are some radically different approaches, each with their own advantages and disadvantages, however it is generally accepted that these systems will demonstrate most of these characteristics:

  • Typically “cloud” based, multi-tenancy systems, offering economies of scale and sharing of data across several member institutions.
  • The ability to record all activity and support business intelligence to detect trends across several networks of libraries.
  • Based on an open architecture and open standards, allowing a) easier and closer integration with an organisation’s other core systems such as student registry, human resources, and finance and b) development of add on functionality by local technical staff.
  • Search and Discovery functionality is de-coupled from the back end resource management operation.
  • Integrated management of print and electronic resources.
  • Flexible and customisable workflow design

The following systems and services which have been characterised as Library Services Platforms. Some are (or are soon to be) available, although none of these are yet fully developed, mature, systems:

Product Supplier
Alma Ex Libris
Chorus Capita
Intota Serials Solutions
Kuali OLE Kuali Foundation
Sierra Innovative Interfaces
Open Skies VTLS
Worldshare Management Services OCLC

Development of these next generation products has typically taken one of two approaches:

Start the new product development from the ground up Retain and re-package the core product, combining and integrating new technologies and services with it.
Advantages: Advantages:
  • Totally re-written, re-engineered, more efficient.
  • Providing more integrated workflows for digital collections
  • Reduced (or removal of) need for integration with other library systems.
  • Many libraries are in no rush to re-engineer their entire workflow, instead wanting to focus on end-user facing improvements.
  • Simpler (lower cost) migration.
  • Fewer bugs to resolve.
  • No loss of functionality (but with much more added).
  • Retain ability to choose and deploy “best of breed” applications.
  • Many libraries are in no rush to re-engineer their entire workflow, instead wanting to focus on end-user facing improvements.
  • Simpler (lower cost) migration.
  • Fewer bugs to resolve.
  • No loss of functionality (but with much more added).
  • Retain ability to choose and deploy “best of breed” applications.
Disadvantages: Disadvantages:
  • Potential high costs of migration on top of purchase and licensing (including staff time, redesign of workflows, change management within organisation).
  • Moving back to “Lock-in” to monolithic system.
  • Possibly not worth the effort and cost of migrating vs the benefits anticipated, at least short term.
  • SaaS rather than true cloud, with the option to run locally, meaning that the supplier (and ultimately customers) may bear the increased cost of supporting multiple versions.
  • Possibly not worth the effort and cost of migrating vs the benefits anticipated, at least short term.
  • SaaS rather than true cloud, with the option to run locally, meaning that the supplier (and ultimately customers) may bear the increased cost of supporting multiple versions.

NB the advantages and disadvantages listed are, for the moment, assumed.

The rise of Library Services Platforms does seem to have reinforced a desire for the “one stop shop” which has the promise from suppliers that it will cover ALL the areas previously (currently) served by separate systems (and potentially more). There are understandable advantages to this as by doing so the overall costs of software development, product management and administration, and of supporting separate products at multiple local customer locations, can be reduced, but with this raises additional issues, such as unwanted “lock-in”, and raised expectations from users (library staff and end-users) that will understandably expect at least an improvement on existing services, not a loss of functionality in some areas.

Off the Shelf, or Build your own?

One traditional view of Open Source may be of “building” your own local systems, conjuring up images of local IT guys hand-knitting a catalogue system. This view is a narrow interpretation of the use of open source software development in an organisation such as a library, and one we need to move away from. The idea of Open Source resonates with libraries who are traditionally inclined to collaborate.

Many commercial vendors base key services and features on open source applications, middleware, and components. This is not the same as downloading a complete application and being able to tweak the core code to fit with local needs, as many libraries with appropriate local expertise are able to do successfully with (for example) DSpace.

Taking a leap of faith

Koha and Evergreen have been established for some time, however the adoption by libraries of alternatives to the commercial proprietary offerings has historically had “mixed” results.

Marshall Breeding observed in 2011: “Kuali OLE, blending both new concepts and open source development, with its completion a year or so away, stands as a tantalizing future alternative”

Kuali OLE is not a true cloud solution, requiring partners to make their own arrangements for hosting, but this has the advantage that with ever increasing commoditisation of IT service components and facilities, institutions could either join together and fund purpose built facilities across on or more sites, or seek the best deal for commercial managed hosting and disaster recovery on a flexible contract. If a better proposition comes along its then a matter of moving from one hosting provider to another, not setting up a whole new system. This also avoids the risks associated of being tied into a single supplier’s vision and development plan.

What’s becoming clear from the approach of the KUALI foundation is that lessons have been learned in order to develop a credible open source alternative. What is needed is something that libraries can believe in and influence to their advantage, whilst being able to build a compelling business case to decision makers.

Some institutions have been operating the same LMS in excess of 10 years, so deciding what to migrate to is a big decision regardless of the circumstances. When carrying out the due diligence in something as significant as replacing an LMS, and the management of project risks, the same level of scrutiny should be applied to proprietary and open source solutions. Summarising one of the speakers at the recent SCONUL KUALI OLE seminar, migrating from an LMS to “anything” else is a risk, but having given the commercial vendors the same opportunity to explain their roadmap and business model, all the directors of the institutions involved (in the decision) agreed that moving to Kuali OLE represented less overall risk. This shows the importance of having well understood governance of the organisation and the product development, and a clear vision for the business model potential partners are asked to buy in to. As Robert McDonald indicated at the event, they are not looking to compete with the commercial vendors feature by feature, but instead deliver the functionality that the partner needs. Kuali are not looking to have every academic library in the world join the partnership, just “enough” to make the model sustainable.

It remains to be seen whether the objectives of the Kuali foundation come to fruition, but the prospect of actually having a financial stake in the development of your own product is compelling. The model is a flexible and pragmatic one, not simply depending on partner libraries to employ their own team of java developers, but for partner libraries to club together and parcel development up potentially to farm out to 3rd parties. This approach may strike a raw nerve with those libraries who have tried and failed for years to their suppliers to carry out bespoke development, offering to pay extra for them to do so.

Scottish institutions will be keeping a watching brief on implementations of both next generation library service platforms, and Kuali within the UK and further afield.

Types of Shared platforms

When considering shared services, we need to unpick the stack of technical service components, understand what is feasible to share between institutions, and then consider the advantages / disadvantages and costs. This is a simplified overview:

Shared Infrastructure

This may consist of components such as processing power and storage, but may also include networking. It may be infrastructure that is managed locally by one institution, contracted out to a 3rd party IT facilities management company, or entirely cloud based with a commercial systems vendor. There is a distinction between sharing infrastructure and sharing application or system instances.

  • Current Scottish consortia providing this type of shared service include the SDLC and the Glasgow Colleges.

Shared Application Instance

This consist of a shared LMS instance where catalogue data is available in one place. This approach can be more economical and offer a reduction in maintenance overheads with only one instance of code to update, however the infrastructure needs to be able to cope with the increased demands of a larger resultant catalogue. Sharing a catalogue from a technical point of view does not necessarily mean that Policies are shared.

  • Current Scottish consortia providing this type of shared service include the Rowan partnership and SEDAR.

Shared Policies

In this scenario, institutions share not only a single LMS instance but also the policies (for example, circulation rules). Discussion at the LMS Day indicated that there is an appetite to discuss how this objective could be reached by making much more efficient use of the expertise spread throughout Scotland but which are duplicated several times over.

  • There are no current Scottish consortia providing this type of shared service.

Technical limitations of Current Consortia & Services within Scotland

For a more in depth analysis of the organisation and services provided by consortia in Scotland, please see  Workpackage 2 Users – Scotland’s consortia landscape.

LMS use within North American consortia are typically based on a shared “system”, and development of functionality for consortia tends to reflect that.

LMS use within Scottish consortia are typically based on a multiple instances of the same systems based on shared “platforms”. (See above, for why development of consortial functionality often doesn’t offer any additional advantages to those partners).

The Scottish Digital Library Consortium (SDLC) has provided hosted (SaaS) services to partner Scottish libraries for several years, following a joint procurement for Endeavour’s Voyager LMS in 1999 between the University of Edinburgh and the National Library of Scotland. In the case of SDLC, the infrastructure is well specified and there is no technical reason why the partner catalogues could not be shared, but this has never been an objective of the member libraries. Without the desire to share circulation, providing each institution with its own instance offers them a number of advantages from a service management perspective, with a little overhead. The Rowan partnership shares a single instance of its catalogue, although not circulation, which is a policy decision.

From a technical, expertise, and experience standpoint, there is no real reason why existing consortial organisations within Scotland could not scale up to operate on a wider basis, but this is probably a moot point with no rush for institutions to jump ship to a different LMS based on a hosted (SaaS) model (although this may up for discussion if Kuali OLE gathers momentum).

A key issue is whether a SHARED SERVICE is born out of an shared OPEN PROCUREMENT which may or may not consider any of the products outlined earlier (allowing institutions to join as and when are able), or whether it is the governance and organisation that is established first, in order to then progress to the next stage of establishing a valid shared service.

Conclusion

The market for Next Generation Library Systems (Library Services Platforms) is not yet sufficiently mature to enable most Scottish libraries to make an informed decision, and may not be for another 18-24 months.

During this time Scottish institutions (both individually, and as part of consortia) will maintain a watching brief on the anticipated uptake of LSP products, and speak to those involved in the implementation at their institutions. The products expected to take market share over the next year to 18 months do not present technical issues for “sharing”, although the organisational and political issues will remain. Scottish institutions may use this time period to decide whether they wish to go their own way, or collaborate with others.

This collaboration may be as basic as a shared procurement, or the establishment of a Scotland wide organisation for the sharing of a future next generation system. In this scenario, Scottish libraries will need to acknowledge that some negotiation and even compromise from each institution may be needed to deliver synergies from the wealth of operational and technical expertise and experience across the country, from which a true shared service may emerge.

Leave a Reply

Your email address will not be published. Required fields are marked *