Transitioning from a Self-developed and Self-hosted ILS to a Cloud-based Library Services Platform for the BIBSYS Library System Consortium in Norway

1 Introduction

BIBSYS,^[1] the organisation providing system related services to the Norwegian Library Systems Consortium, often referred to as the BIBSYS consortium, recently moved from its self-developed and self-hosted Integrated Library System (ILS) to the Library Services Platform Alma, delivered by Ex Libris as a cloud-based service.

The change started in 2008, when the BIBSYS Board established a working group with the aim to analyse future needs for the Consortium’s ILS. Relevant new library systems solutions available internationally where found to be getting more and more complex, leaving the option of developing the next generation system by ourselves as too expensive. At the time of the report, the global availability of systems providers is sufficient to allow appropriate competition.

Based on the report, BIBSYS entered into a procurement process for a Next Generation ILS in 2009 that ended with signing a contract with OCLC for their WMS and WorldCat services in 2010. The services operated until the end of 2012. The contract was cancelled in 2012,^[2] and BIBSYS established two new procurement processes, one for a Discovery and Delivery-service to go live in 2013 and one for a Library Services Platform to go live by the end of 2014. In 2012,^[3] BIBSYS signed a contract with Ex Libris for Discovery and Delivery, for Primo the system was live in August of 2013. For a Library Services Platform, BIBSYS signed a contract with Ex Libris for Alma in December of 2013,^[4] and the system was live for all of the Consortium’s members on 3^rd December 2015. This article gives a brief description of choosing and implementing the new Library System for the BIBSYS Library System Consortium.

2 The BIBSYS Consortium

BIBSYS supplies library and information services to more than 100 Higher Education (HE) and research institutions, sharing the same bibliographic records in addition to their local data (holdings, classification, etc.). The Consortium comprising all Norwegian University libraries, University college libraries, the National Library, medical libraries and a number of research libraries. The sizes of the different consortium members range from institutions with a few employees to large institutions (e. g. universities) with a hierarchical structure and hundreds of employees.

Norwegian HE-institutions has a long tradition of joint solutions and services, mainly because the government finances most of the institutions. Even though the size of the institutions varies extensively, their needs often are comparable.

3 The current situation

Formally, all of the consortia members transitioned from the old legacy ILS onto Alma over a five-week period during late October and November of 2015. The old ILS is no longer in use and will be closed by the end of 2016.

BIBSYS introduced Ex Libris Primo as the Consortium’s Discovery and Delivery Solution in August of 2013 and all members where using Primo, named Oria in Norway, by mid-2015.

Halfway through 2016, the BIBSYS organisation in cooperation with several of the larger HE-institutions and Ex Libris are still working to fulfil the agreement for the delivery of Alma. It is still not perfectly clear whether our aims and objectives for a Library Services Platform have been fulfilled completely.

4 Aims and objectives of migrating to a next generation library system

Based on the working groups’ suggestion, BIBSYS and representatives from the consortium members established the objective of the purchasing project in 2009. It was a clear assumption that the current ILS was subject for replacement. However, the consortium was not interested in a traditional ILS, only a Next Generation ILS was of interest in 2009. When the procurement process was repeated in 2012/13, the objective was formulated slightly different. Among other changes, there was a change from a Next Generation ILS to a Library Services Platform (LSP). The objectives for both the first and the second procurement are shown in their full versions in appendix 1 to this article.

The objective of the second procurement was to purchase a Library Services Platform that supports a Service Oriented Architecture, is adaptable and can be easily integrated and modified to suit the needs of the consortium. The new LSP was to be in full-scale operation by the end of 2014 and was based on a technology that has an expected lifespan of at least a decade.

It was essential that the LSP provides a platform with services that would enable BIBSYS to implement the extensions that the consortium needs. Some of the extensions, such as functionality supporting the National Library, were to be fully implemented by BIBSYS before the consortium could start to use the rest of the system. Due to this, BIBSYS needed to have access to standard services and APIs at an early stage.

Based on the objectives and the fact that no suppliers necessarily would be disqualified on the grounds of not meeting a “MUST” requirement (listed appendix 2 of the article), the project established specific goals as a basis for the “MUST” requirements. The goals for the second procurement are listed below:

1. The new system must be a modern LSP that will provide the core functionality of a traditional ILS, but offer more efficient workflows addressing any media types. The library services also need to be closely integrated with services in other products used by the institutions, and services and workflows must be able to adapt to rapidly changing needs. This will, in total, extend the requirements to the functionality of the LSP and create additional requirements to its architecture.

2. Since BIBSYS is a service provider for a large consortium, it is essential that the LSP provides group functionality, e. g., the ability to configure several institutions in a single operation efficiently. It must also accommodate the requirements of academic institutions of all types and sizes, from single-site libraries to the largest libraries comprising several departments, as well as requirements from the National Library.

3. BIBSYS expects a product with unified media handling of media types regardless of format or acquisition process. This unified management should not only be visible at the user interface, but also through the underlying services. All new functionality must be developed to support the unified handling of any media.

4. It is an option in the contract for the contractor to offer a discovery system in addition to the LSP. However, it is essential that the LSP is flexible and easily integrated with other Discovery products.

5. The LSP must interact with other systems within the enterprise. Communication between the LSP and other systems must use open, standard protocols. The LSP must be able to use services from external providers and integrate these services in the system. In order to achieve these goals and provide a system that will be as flexible and robust as possible, the architecture used in the system must be a Service Oriented Architecture (SOA).

The reason we established the hierarchy of Objectives-Goals-Requirements was that we wanted to have the possibility to exclude one or more suppliers in the procurement process on the grounds of them not fulfilling one or more of the goals. The objective by itself was not deemed sufficient and relevant for this use. All requirements was labelled with either MUST or SHOULD. If a Supplier did not fulfil a MUST requirement this was not alone a reason for disqualification, but the score was reduced according to the degree of severity. However, if e. g. a Goal requirement was not fulfilled, that could be a reason for disqualification. All MUST requirements related to award criteria was assigned scores as indicated below. SHOULD requirements denoted a desirable feature and gave extra credit.

5 Award criteria applied for the system’s choice

The contract was awarded to the supplier who had the most economically advantageous tender based on the award criteria listed below. BIBSYS used the issued documentation in form of objectives, goals, MUST- and SHOULD requirements provided in addition to the test system and further information provided by the Supplier as the basis for the evaluation.

Total Cost of Ownership was evaluated against relevant requirements.

Functionality evaluated the written answers to the tender, the demonstration and the result of the testing of the product in addition to relevant requirements.

Extendability emphasized relevant requirements.

Security of supply favoured a Supplier’s substantiated ability to support BIBSYS’ development and to deliver the fully integrated and configured solution ready for full-scale operation by 1 January 2015. It further favoured supplier’s that ensured years of trouble-free operation. This criterion was evaluated against relevant requirements.

Appendix 3 is a list of the award criteria with the corresponding sub-criteria.

6 Involvement of the library community

BIBSYS undertook the official procurement of both Alma and Primo on behalf of the Consortium. The member institutions are involved on a daily basis through an Advisory group, consisting of representatives from the larger HE-institutions in the Consortium as well as the National Library. The BIBSYS Board has three Library directors among its members.

Based on the objectives and goals, the process to establish a requirements list for the procurement was done in cooperation with members of the Advisory group. In addition to this, five institutions were dedicated as Vanguard institutions, three large University libraries, the National Library and a small library. The idea was that those institutions would have access to Alma a lot earlier than the rest of the Consortium (with test data from their own holdings). Their task was to assist BIBSYS in testing the system and confirm that the data migration, processes and procedures worked as supposed. BIBSYS established five working groups from the same institutions helping with establishing training for acquisition, E-resources, fulfilment, and metadata. In addition, one working group focused specifically on issues relating to small libraries.

7 Advantages of the new system

During the six-month period since go-live, the focus has been to get the system up and running with a primary focus on user management, appropriate configuration, and consortium functionalities. In general, most institutions are satisfied with the new and modern system. It gives them a modern user interface, which can be customized to the librarian’s tasks and responsibility. Alma is a next generation library system, meaning it can manage the process of acquiring, describing, and making available all library resources better than the old ILS.

The BIBSYS consortium has collaborated over many decades by using a common library system based on a shared database. By using Alma and being part of a global community, the consortium constantly updates his system to the global academic library needs as well as access to a global knowledge base.

The library resources and services have changed over the years. Recently, the increase in e-resources and the opportunity of making the library’s collection available to the end users in a more efficient way achieved a system change. The functionality for e-resources in Alma is very effective and there is a huge improvement compared to the old ILS. The e-resource functionality is the most desired and appreciated advantage, where each institution can easily activate and perform license management. Alma supports consortium management of e-resources and each institution can customize the embedded link resolver. Managing the e-resources in one place to make it available for many institutions is necessary for the consortium. The functionality was not available at go-live, but became available in a later release.

Alma is flexible and has a powerful configuration module, although limited to the features available in a standard system. The larger institutions appreciate the flexibility and the opportunity to configure Alma. The smaller institutions however, find Alma complex and difficult to understand. Alma analytics has advanced analytic capabilities, and the consortium members look forward to experience the benefits of having good reporting opportunities.

Compared to the old ILS, Alma is quite different to the user. It was challenging to change from a command-based system adapted to the workflows to a modern standards based web application. So far, early adopters of Alma as well as several consortium members has voiced an experience that it will take 1 or 2 years to get used to and get the most out of Alma. The feedback received from the consortium members varies, they appreciate different functionality and they experience different challenges.

8 Challenges related to a cloud-based system

Although there are many advantages with a cloud-based solution, there are also challenges. One obvious challenge is data protection and security, which will be discussed in a later chapter. Cloud-based systems seem to have more frequent releases of updates, new features, and fixes to their solutions. This may be a challenge as the consortium no longer have the choice of deciding for themselves whether or not to upgrade to the latest version or not. For BIBSYS, having developed several extensions and applications linked to Alma via APIs and available services, it is a challenge to make sure that our extensions and applications functions perfectly with every new release of Alma. Any new release of the software must be thoroughly tested with all integrations before it is deployed, which require test procedures and test environment. Unfortunately, a proper test environment is still not available from Ex Libris.

9 Standardization of applications and workflows in libraries

The BIBSYS consortium has benefited from a tailor-made ILSdelivered more or less comparable to the concept of Software as a Service for more than 40 years, providing lots of consortium functionality. Having been used to a system that is customized to the library’s workflow and often with relatively quick responses to reported needs for changes, the transition to Alma and a vendor that must to take into account the needs of the global community is noticeable. There is still a need to develop a lot more consortium functionality within Alma.

Being in a consortium, where all of the institutions used the same system and more or less having variations over the same work-flow, the change to Alma really was about changing from one system to another as well as changing from one work-flow to another. The libraries will probably need to use Alma for at least one year in order to optimize workflows and processes and to maximize the benefits of the new system.

Having been used to a well-developed Inter-Library-Loan (ILL) functionality within the larger Norwegian library community, the transition to Alma was a challenge. The Norwegian Library System Vendor Group including the National Library initiated a process to develop a Norwegian NCIP-profile independent of the decision to procure Alma. The fact that Ex Libris has chosen to use ISO-ILL in Alma, necessitated that they needed to implement support for the Norwegian NCIP-profile separately. The implementation was not straightforward, but should be functioning properly by the end of 2016, a year after go-live. The lack of functionality in ILL has created a lot of frustration and extra work both at the public libraries and within the consortium.

The National Library in Norway has several special needs (legal deposit, large digitization projects, and automated warehouse functionality) that the other libraries in the consortium do not have. To accommodate for those needs, BIBSYS tailored the old ILS to the National Library’s needs over years. By using standard Alma functionality and available APIs BIBSYS has implemented the most important requirements for the National Library. It has been a challenging journey as the service platform was not as available as expected and the APIs did not perform as well as expected. Neither did the APIs give access to the necessary data nor were several APIs missing during the initial phase of the implementation project.

10 Handling changes and related reluctances

The procurement process as described earlier has been a long and cumbersome one in a way. It started in 2009 and ended in 2015. Having to end one process and then restart caused a delay of approximately two-three years. This has obviously caused some strain on the consortia members as well as the BIBSYS organization. The procurement process has been as open as possible, given that some of the commercial details needed to restrict from the public.

BIBSYS normally organizes an annual user meeting, which is an appropriate arena to inform about the procurements. In addition regular newsletters where distributed to all of the library employees. Separate seminars, some of them with OCLC representatives in the first procurement and Ex Libris representatives in the last procurement where organized in order to provide as up-to-date information about the process as possible. In addition to this, representatives from Alma early-adopter institutions were invited to share their experiences.

The advice received from several early adopters was to go-live with Alma before considering reorganizing the local libraries as well as workflows. Whether or not everyone has adhered to this, it is not clear.

Even though some of the employees seemed reluctant and anxious in early phases, the feedback received lately has been that mostly everyone is satisfied with a new and modern system with a modern user interface.

11 Challenges of data protection, data security, and the ownership of data

Several laws in Norwegian legislation cover data protection and data security:

The Personal Data Act^[5] protects information about individuals to avoid abuse and unnecessary spreading. The act defines the controller as “the person who determines the purpose of the processing of personal data”, e. g. the university that has a registry of their staff and students; and processor as “the person who processes personal data on behalf of the controller”, e. g. BIBSYS data receives data about patrons on behalf of a university. The relation between controller and processor is regulated in a data processing agreement. BIBSYS has one agreement with each of the 104 institutions comprising the consortium. In addition, BIBSYS has a data processing agreement with Ex Libris, where BIBSYS is controller and Ex Libris is processor. The agreement describes which data types that are processed, how they are processed and how they are secured. BIBSYS is not processing any kind of sensitive data. About half of the agreements include the Norwegian national identity number amongst the data being processed.

The Copyright Act secures a creator her right to literary, scientific, and artistic works. The collections in BIBSYS mainly comprises metadata on works, but for future use it is important that full text, etc. stored in BIBSYS systems are properly protected.

The Norwegian government has generally declared ownership to metadata stored in BIBSYS systems. This is not voiding the single institutions right to create, update, and delete their contributions to the BIBSYS joint database.

The tender had the following requirement related to ownership:

“The Customer shall have the right of ownership of all data that are handed over to the Contractor for processing, and that are stored or processed by way of the deliverables under this Agreement. The same shall apply to the output from the Contractor’s processing of such data.”

The metadata in our previous system was open to the public for free use. The tender had this requirement on licensing:

“The Norwegian government wants public data and digital content that is publicly funded, to be available to everyone. It is stated in the guidelines to governmental institutions that their data should be available in machine-readable formats. It is strongly suggested that the data should be licensed with an open and free-to-use license. A Norwegian national license for this purpose (NLOD2)^[6] has been created. As governmental institutions with governmental funding, the vast majority of the member institutions in the BIBSYS consortium, along with BIBSYS itself, are affected by these guidelines and therefore obligated to make metadata available and licensed.”

Using a cloud-based service such as Alma raises a challenge to data protection. The Personal Data Act requires (in section 29):

“Personal data may only be transferred to countries, which ensures an adequate level of protection of the data. Countries which have implemented Directive 95/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data meet the requirement as regards an adequate level of protection.”

To ensure this, all Alma services provided to BIBSYS runs on computers physically located in EU countries that fulfil the requirement cited above.

12 Management of bibliographical metadata, local data incl. holding/license information and the usage of authority files

Both, the previous BIBSYS ILS as well as Alma are based on MARC. However, the old system used a local dialect of MARC, named BIBSYS-MARC. There are many similarities between them, but also some major differences. BIBSYS-MARC had:

1. no position-based control fields,

2. the control data in subfields,

3. no use of indicators,

4. a particular model for multivolume works (this model gave us extra challenges during data migration).

In the old ILS, the multi-volume works were described on multi-records in a hierarchy. Low-level records would be very poor in many cases of bibliographical information. As single records, the low-level records (which actually pointed to the physical items) would be without bibliographical value. When being converted, these had to be enriched by information from higher levels. The challenge was to create a single, meaningful bibliographical record composed of several higher-level records. The converted records are not quite in accordance with correct cataloguing, but they are rich enough to be interpreted correctly for library use.

Alma uses standard MARC 21, and new multivolume works are catalogued in a different way than the converted records. However, new volumes of older works (i. e. initiated in the old system) are being recorded following the pattern of the migrated volumes. Other types of records (other than multivolume works) caused very little problems on conversion to MARC 21.

When it comes to cataloguing rules, the same rules as we used with the old ILS are still in use. A Norwegian translation (slightly adapted) of AACR 2 are one of those. In the old ILS, a long list of policy statements and deviations from the cataloguing rules was developed over the years. When changing to Alma, the opportunity arose to get rid of most of these, a decision the Consortium is quite happy with!

The users require guidance, and BIBSYS has created a toolbox to take care of this. The toolbox consist of written documentation on MARC 21, cataloguing rules and step-by-step-guidance on certain types of library material, all written in Norwegian.

The management of bibliographical metadata in Alma is quite flexible, and there is a certain freedom in defining local MARC tags. It is relevant to mention that as a consortium, local exists on two levels. Regarding standard MARC 21, MARC fields are defined for shared use in the consortium. These are local in accordance with MARC 21. Then there are local defined by the consortium, but used locally in each institution. It all seems to work fine in Alma.

Alma provides freedom in indexing these fields, which is very satisfying, but making specific searches in subfields are not possible. Limiting searches to particular MARC fields and specific subject headings systems are not possible, but would have been a useful feature. To sum it up, Alma is flexible, but not flexible enough.

Regarding information about holdings, Alma uses the MARC 21 Holdings format in addition to an item scheme. MARC 21 Holdings was unfamiliar to BIBSYS, and has rarely been used in Norway at all. In general, there were a lot more to learn about Holdings than regarding bibliographic information.

Electronic resources may need some special attention and are kept in a specific environment in Alma, unlike the old ILS. This has some effect on the cataloguing, since linking between the material types print and electronic is not as adequate as it used to be. The way Alma differentiates between electronic and digital resources was surprising and has caused some frustration.

The BIBSYS authority file consists of about 2 million authority records for persons, corporations, conferences, and uniform titles. Due to the need of some advanced maintenance of the authority file (split, merge, etc.), export to VIAF and the possibility to allow third parties to interact and contribute to the authority file, it was decided that the master should reside outside Alma in a standalone application. The integration with Alma is realized via the protocols OAI, SRU and SRU-U. This solution gives BIBSYS the flexibility to allow others to access, use, and contribute to the authority file without locking it inside Alma. The authorities also plays an important role in the semantic web/linked data representation at BIBSYS, and there are plans to include other types of authorities into the file, like subject headings, and possibly creating a register of works. This requires efficient handling and easy access to the structure, application, and database. Having the authority file outside Alma gives us the possibility of providing functionality that Alma does not yet support. Authority control is quite exciting in Alma. It seems to offer a lot of functionality, but it does not always work as expected. There are still adaptations needed before the function acts satisfactory.

Configurations in Alma are plentiful and almost anything may be configured. This makes it possible to shape Alma according to our needs.

Normalization rules and merge rules are features new to the Consortium, and very much appreciated. These are powerful tools making it possible to manipulate the data, but as in other areas it cause problems due to the out-of-the-box search possibilities not being sufficient to create the sets of records needed to work upon.

13 Roles and tasks of Library networks with network databases in the cloud

A library network is not a clearly defined entity, and how it is influenced by the cloud-based network databases of next generation systems probably varies a lot. The BIBSYS Consortium, being used to a shared database for more than 40 years, is well equipped to transition to a cloud-based network database.

The consortium is used to BIBSYS taking responsibility of performing many of the tasks concerning most or all of the consortia members. The functionality of the Alma network zone is still not well developed, and it is not obvious, which tasks in the future BIBSYS or the individual institutions in the future will perform. Traditionally, the smaller institutions have received more assistance from BIBSYS than the larger institutions. The fact that Alma is considered to be a very demanding system to operate by most of the smaller institutions would suggest that BIBSYS will continue to perform operations on behalf of them. On the other side, having a new system that makes it possible for the single institution to perform the different tasks themselves might lead to a change for BIBSYS.

Regarding the Alma community zone, the consortium is excited about this feature and look forward to explore the opportunities.

The consortium’s advisory group recently distributed a survey in order to identify future needs, resources, and competencies among the member institutions. A survey response rate of 73 % provides a good basis to identify the situation and to recommend the road ahead to the consortium, in particular the future role of BIBSYS and which services to provide. In general, the institutions agree that there is considerable benefit in collaborations on a shared catalogue; among other things, it ensures better metadata.

Being a national network, the consortium still requires BIBSYS to provide user support, guidelines for the consortium operations, FAQs, common practices, templates, and training beyond Ex Libris deliveries. BIBSYS will continue to provide system integrations and extensions to Alma in addition to further development of various services.

14 International cooperation between libraries

The BIBSYS consortium is based upon the concept of cooperation. The consortium members have always seen the advantages of having a common system with shared data and as such being part of a cooperating network. One of the reasons for the consortium to go from a tailor-made system and to purchase a standard system was the desire to be part of a larger international network. It will be easier to establish relationships with other libraries when we use the same system and thereby share experience, best practices, etc. Whether the international cooperation should be limited to a European network has not really been discussed. It would seem that the possibilities inherent in the next generation library systems of cooperating on an international or even global arena might be more interesting than limiting the cooperation to Europe. The same probably holds true for library clouds and indexes.

Appendix 1 – Objectives for the BIBSYS orocurements

Procurement initiated in 2009

The objective of this tender is to purchase a next generation solution for the libraries. The solution must include discovery tools, electronic resource management, and link resolver services that are currently divided into separate products. It must take into consideration the changing user behaviour of the Google generation.

The new solution must be in full-scale operation by the end of 2012 and be based on a technology that has an expected lifespan of a decade or more. The solution must be able to interact with several systems that are, or will be in use in the HE-sector. Initially, this includes interaction with e. g. acquisition and invoicing systems. It must support uniform management of the full life cycle of all types of resources. In order to achieve these goals and get a system that will be sufficiently flexible and robust, the architecture used in the system must be fully based on a service-oriented architecture.

Responses to the call for interest implied that a next generation solution is not on the market today, but that there are initiatives and projects in an early phase. The BIBSYS consortium would like to purchase the final software product. In order to secure that the solution will meet the expectations, BIBSYS must have sufficient knowledge of the contractor’s project as it progresses and has the possibility to influence the direction of the project.

The contractor is invited to suggest how this can be achieved. The consortium may need special adaptations that will not be provided by the contractor’s ILS. BIBSYS will be responsible for the implementation of these adaptations in parallel with the contractor’s project. BIBSYS must therefore have access to standard services and interfaces at an early stage.

Procurement initiated in 2010

The objective of this procurement is to purchase a modern Library Services Platform (LSP) that is implemented with a Service Oriented Architecture and is adaptable and can be easily integrated and modified to suit the consortium needs. The LSP must be in full-scale operation by the end of 2014 and be based on a technology that has an expected lifespan of at least a decade. The LSP product to be offered must be in full-scale operation in other institutions at the start of this tender process. LSP products that still are in development and only have “early adapters” will not fulfil this requirement.

It is essential that the LSP handles all media types in a uniform way, regardless of format or acquisition process. This uniform management should not only be visible at the user interface, but also be reflected by the underlying services.

The LSP must provide a platform with services that will enable BIBSYS to implement extensions needed by the consortium. Some of the extensions, in particular the functionality required by the National Library, must be implemented by BIBSYS before the consortium can start to use the system. BIBSYS must therefore have access to the necessary standard services and interfaces at an early stage.

The LSP must be offered as a SaaS or Cloud service with a high availability.

It is expected that the LSP will be in full-scale operation including the Norwegian extensions (implemented by BIBSYS) by the end of 2014, and as such, ready for final testing by the end of second half in 2014. However, if the procurement process is delayed in any way that leads to the contract being signed later than proposed in this tender, BIBSYS has the right to adjust the date for when the system is expected to be in full-scale operation.

Appendix 2 – MUST-requirements for the BIBSYS LSP procurement in 2013

Appendix 3 – Complete list of award criteria for the BIBSYS LSP procurement

Total cost of ownership – 20 %

This criterion will be evaluated against the relevant requirements listed in the draft Agreement.

Functionality – 45 %

This criterion will evaluate the written answers to the tender, the demonstration and the result of the testing of the product in addition to the relevant requirements in the draft Agreement.

Extendibility – 15 %

This criterion will emphasize the relevant requirements in the draft Agreement.

Security of supply – 20 %

This criterion will favor a Supplier’s substantiated ability to support BIBSYS’ development and to deliver the fully integrated and configured solution ready for full-scale operation by 1 January 2015. It will further favor a supplier’s that ensures years of trouble-free operation. This criterion will be evaluated against the relevant requirements in the draft Agreement.