2022-01-14 19:45 Posted onShanghai
case/example/introduction/introduction
Issue 01, 2022
Author: Jenn Colt, Debra Howell
Compiler: Ji Ting, Zhang Chunjing
This article is selected from: Colt, M., & Howell, D. (2021). Cornell Library FOLIO Case Study. International Journal of Librarianship, 6(2), 13-20. https://doi.org/10.23974/ijol. 2021.vol6.2.205
Introduction
Cornell University is a private university with a public mission. After 20 years of using Ex Libris’ Voyager as the library’s Integrated Library System (ILS), Cornell University Libraries completed its migration to the open source platform FOLIO on July 1, 2021. This case study documents a library’s journey from choosing FOLIO to going online.
1. Introduction
Cornell University is a private university with a public mission. Cornell University, with a student body of approximately 25,000, is a private endowment university, a member of the Ivy League/G8 and a partner of the State University of New York. Cornell Libraries adheres to the mission of Cornell University and has 20 different physical and digital libraries, a collection of 8.5 million books and 1.7 million e-books, and approximately 400 employees.
After 20 years of using Ex Libris’ Integrated Library System (ILS) Voyager, Cornell Library migrated to the new open source platform FOLIO on July 1, 2021 - Future of libraries is open, meaning the future of the library is open.
The road to FOLIO
Cornell began exploring options for replacing the Voyager system in the early 2010s. A committee, led by then-Chief Technology Strategist Dean Krafft, worked with our colleagues at Columbia University to analyze alternative ILS environments. This is called the 2CUL project. 2CUL also includes other forward-looking ideas such as shared collection development and integration of technology services. We wanted a system that fostered deep collaboration and led in new directions. After evaluating Alma, we decided to avoid overreliance on a single vendor, so we started looking at Kuali Open Library Environment (OLE). We believe OLE best aligns with our commitment to open source and our desire to be directly involved in development. Shortly after we decided to join Kuali OLE, the community made an important decision to fundamentally change the direction of the project, discontinue the Kuali platform, and rebuild the code base. This change gave birth to FOLIO, which stands for "Future of libraries is open". Therefore, Cornell Libraries began participating in the FOLIO community in early 2016.
Jason Kovari (Director of Cataloging and Metadata Services) noted: “We decided to implement OLE because we believed in open source. We were tired of being tied to vendors and tired of the lack of agency in system development, which was detrimental to implementing the book. The functionality of the pavilion is vital. And, we see it as a means and a way to support an evolving system that will evolve with our needs. FOLIO is built on this philosophy. We are not Because FOLIO is implemented for any specific set of features; conversely, the reason we chose FOLIO is that we can determine the direction of development and have a very good community of peers."
Soon after FOLIO was proposed, Cornell University began to contribute manpower, material and financial resources to help the establishment of FOLIO. The biggest factors in our continued efforts to develop and implement FOLIO include: open access vision, microservices architecture, core library management capabilities, batch production processes, the ability to access and modify source code, multiple metadata options (MARC, non-MARC, Linked data, etc.), and the integration of electronic resource management (ERM) functions.
2. Implementation
After several years of FOLIO development, in 2019 Cornell University established a team to manage the implementation of FOLIO, with the goal of going live in July 2020. We assembled an implementation team with members from across key parts of the library, including: reporting, finance, metadata management, access services, user testing, interviews, series processing, cataloging, electronic resource management (ERM), training, infrastructure, Integration, discovery and data migration. In addition to "leading" in these areas, many library staff become subject matter experts (SMEs), help with training, or participate in FOLIO community special interest groups (SIGs). The library also hired an information technology project manager to lead the project.
The first decision we need to make is whether to sign a hosting contract with a provider or manage FOLIO ourselves. With appropriate resources, libraries can manage, maintain and upgrade FOLIO themselves. However, it became clear that we did not have enough personnel to manage it ourselves. After multiple analyses, Cornell University selected EBSCO to provide hosting and migration services. EBSCO's implementation consultants were valuable partners in our migration and implementation process. One of the best things about FOLIO is that it's completely customizable through settings, and one of the hardest things about FOLIO is also that it's completely customizable through settings. Implementation consultants provided support, guidance and solutions throughout the process, helping us choose the features, settings and options that best suited our operations.
Implementing a system under development requires a unique set of challenges. The success of system implementation depends on FOLIO's development staying on track. In December 2019, we realized that we needed to evaluate the possibility of launching FOLIO in July 2020. FOLIO development uses Jira to track all open features, so we created a Jira dashboard that is essential for managing our implementation. The Jira dashboard shows the ranking of features we need at launch, one quarter after launch, and two quarters after launch. To evaluate our decision to go live in July 2020, we ran through the ranking of all features that would be needed at launch and decided whether they were required features, features that could not be released in the short term, or features that could be replaced with other solutions. Our guiding principle is that we can deal with some of the pain points involving library staff, but all user-facing features must work properly. In December 2019, we identified 22 must-have features that would not be available before July 2020, so we decided to postpone their launch by one year to July 2021.
At the same time, Cornell also migrated its ERM system from ProQuest Intota to FOLIO ERM. This project is led by Cornell’s Peter McCracken (Acquisitions and Electronic Resources Strategy Librarian) and Subject Matter Expert (SME) Emma Raub (Electronic Resources Librarian). The reason this project can move forward is that it is completely independent and can be fully integrated into FOLIO when the conditions are right. In January 2020, Cornell successfully implemented FOLIO ERM.
After deciding to postpone the launch to 2021, we focused on solving these must-have features. Many must-have features are under development in the FOLIO project. We track these features closely and if they need to be reordered, we'll point out their importance. For other required functional items, we will explore other ways to explore our ideas. We collaborated with the University of Chicago, Texas A&M University, and Duke University to develop the Online Computer Library Center (OCLC)-Single Record-Import feature. We undertook the functions of automatic input of the accounting system and automatic export of circulation logs, and contributed the code to the FOLIO community.
Cornell Libraries have custom integrated many other applications, including:
Many of these integration features require development. Some are developed by the FOLIO project, some are developed by vendors, and some are developed in-house. We allocate a lot of time to testing the integration of the system. However, the FOLIO release version we planned to launch was delayed by two months. This left us about three weeks to complete the integrations and test them. Therefore, when we do system cutting, some integrated components do not work. For example, BorrowDirect works for borrowing books, but not for returning them. We completed the integration within a few weeks of going live.
In March 2020, the global COVID-19 pandemic kept most library staff at home for the next year. The remaining implementation work and rollout of FOLIO will occur remotely or, in some cases, in a hybrid environment. Because FOLIO is a global community, in many cases we are used to working remotely. We have also felt the impact profoundly in other areas, such as employee training and engagement.
Considering that most of our training is conducted online, starting in February 2021, we began a layered training approach to prepare for go-live. As part of each release cycle, the FOLIO development community holds a Bug Fest. During the bug-catching session, all released features are tested. Cornell uses bug-catching events as a way to get employees involved in FOLIO. Many early bugfest testers have become our FOLIO subject matter experts, helping others in the library solve problems. We created a training team to conduct FOLIO demonstrations and hold feature-specific training sessions, all of which had to be done via Zoom due to the pandemic. Each session was recorded and made available online. We created a Confluence page with FAQs and anecdotes, and sent weekly emails delivering project news and training information. In the end, we decided to stop most circulation functions 10 days before going online to give Access Services staff a chance to rest and continue FOLIO training.
data migration
The data migration began two years before Cornell began using FOLIO. We took a team-oriented approach with the data migration as part of Cornell's larger implementation team. Two programmers also work on the data migration team, one focusing on bibliographic data and the other on interview, user, and circulation data. Because Cornell partners with EBSCO, their role as host allows us to focus on extracting the data from Voyager and mapping it to FOLIO, while EBSCO handles the process of loading the data into FOLIO because they have direct access to the database more efficiently.
Listed below are some of our experiences and lessons learned in the data migration work of the project.
Start by cleaning your data
Early in the migration process, a team from the library's technical services department was tasked with starting the data cleanup process. This group focuses on cleaning up bibliographic, collection and entry records. Because FOLIO has a faceted navigation and retrieval system in the collection, it is important to cleanse the bibliographic and collection data to enhance its search capabilities and improve its presentation in the FOLIO collection.
Bibliographic information is the largest data pool that needs cleaning, but there is work in other areas as well. The Finance Department simplified the library's funding structure, the Public Services Department simplified circulation rules, and the Procurement Department cleared unnecessary purchase orders. These cleanups have led to increased revenue and opportunities. For example, consolidating individual funds into team funds as part of the financial cleanup gives CUL greater flexibility in moving allocations.
Work closely with data users
Cornell's data migration team meets regularly with various departments in the library to learn about their work. While user experience may not seem like part of a data migration, taking a deeper look at the workflows and behaviors of the people working with the data will allow you to make informed decisions about how your data should be migrated under the FOLIO framework.
Understanding the workflows powered by data can help determine which data to migrate in what form. Through extensive engagement with users, we also encourage them to explore FOLIO. We help them understand what their jobs will look like in the new system so they can provide us with more and better information based on their data needs.
In addition to revealing what data needs to be migrated and where, we also discuss with users what data does not need to be migrated. For example, in Interview, we decided not to migrate closed purchase orders, which reduced the amount of data that needed to be migrated and reduced the amount of cleanup required. In terms of circulation data, we only migrate open borrowing and borrowing data involving fines and fees.
Because FOLIO's circulation rules will greatly simplify the rules in Voyager, the migration team also looked at how to change the data fragments that make up the circulation rules (such as borrowing policies and entry types) during the migration to make the FOLIO circulation rules work.
In the process of this work, it is also very necessary to participate in the FOLIO community. We participated in the Data Migration Special Interest Group and organized several conversations with other libraries migrating from Voyager to FOLIO. The FOLIO community was critical to the success of our data migration, just like it was in other areas of the project.
Document data mapping
Data migration naturally requires a lot of documentation. We created a data mapping spreadsheet for migrating data from Voyager to FOLIO.
We kept a spreadsheet of each entity in FOLIO and then mapped the data elements from Voyager fields to FOLIO fields. We also documented how to extract each data point from Voyager. This is necessary because while some fields in FOLIO are part of one entity, they are pulled from multiple entities in Voyager. There are also some fields that simply don't exist in Voyager, so their contents must be inferred based on various data points in Voyager in order to be mapped into FOLIO.
Prepare a migration plan for multiple iterations
We started testing migrating data to FOLIO a few months before going live. Doing so allows us to uncover missing data issues. Migrating our own data to FOLIO was also a critical step in helping employees understand FOLIO so they could see holes or issues in the data.
When the host configures a sandbox system that our employees can access, we load the data into the sandbox and then have employees test and inspect it and give us feedback. While our own reports and logs allow us to understand patterns and issues in the data, manual inspection of the data by actual users is extremely useful in uncovering overlooked issues and uncovering data points in the initial mapping.
Provides reporting and logging of migrations
EBSCO provides us with reports for each migration iteration, which allows us to fix issues as they arise. Logging needs to contain information that allows users to trace data during the extraction, transformation, and loading processes. We make sure to embed identifiers from Voyager in all data in FOLIO so that we can both maintain relationships between data and track issues that may occur.
Each migration iteration generates a large amount of data that needs to be analyzed, processed and then evaluated. Sometimes logs show bugs in FOLIO software that need to be reported and handled by the FOLIO community. Occasionally, logging will point out problems in Voyager data that need to be corrected. There are also cases where the data points required by FOLIO are not provided by Voyager and need to be specially generated for migration. In some areas, it is necessary to set a default value for a field when Voyager does not provide the required data point.
Carefully plan the days before system cutting
The iterative migration process gives us the opportunity to calculate the time required to load data into FOLIO. This helps us plan the time between deactivating Voyager and starting FOLIO. We created a sequence of operations that told us when various types of data were loaded during the conversion and ensured that this data was in place before we opened the new system to employees and the public for use. Some data migration work continues even after go-live, particularly data that is not part of the current or discovered pipeline.
After FOLIO went online, we spent about 6 weeks continuing to migrate and clean the data. At that time, our data migration had been successful, but we could continue to optimize our data in FOLIO. Our approach includes listening carefully to the needs of FOLIO users, carefully considering the differences between Voyager and FOLIO data models, and working with our hosts.
3. Project management challenges and suggestions
Communication is the most important project management tool when implementing an open source system; especially a system that is still growing and evolving. It is necessary to strike a balance between unconditionally supporting the project and not bringing too many negative effects. Cornell implementation project leaders hold monthly “FOLIO Friday” meetings that include project updates, timelines, and Q&A sessions. We found that staff were more receptive to honest assessments of the health of the program, as well as factual details about those areas that were impacted.
In addition, effective risk management is essential. You may feel like you are constantly putting out fires. However, this is inevitable when managing the implementation of a system that is still under development. It is not possible to perform a gap analysis using a list of features and a list of requirements. The FOLIO implementation is a large, complex project with many moving parts. Based on our experience, we recommend cultivating a decentralized yet unified approach. We identify a champion for each functional area, and program leaders must trust that the champion in each area is making the best decisions for Cornell and the community and asking every big question.
online
The weeks leading up to the launch on July 1, 2021 were chaotic. Several problematic features are on the verge of being unable to be released online. Employees are tired of more than a year of epidemic, and there is some emotion about cutting off ILS as the highest priority. And like Conall, large libraries were originally planned to be online at the same time. All have been delayed. The implementation team continuously re-evaluates the project, and the library executive team evaluates the impact of the project and provides ongoing guidance and leadership.
One by one, we solved one key issue and completed integration and data migration. We are in constant communication with library staff via Zoom meetings, email, and the Cornell Library Slack channel.
The library’s transition to FOLIO is not only a milestone for Cornell University, but also a milestone for the global library community. Cornell University is the first major research library in the world to use FOLIO, and other libraries are learning from our experience. When implementing a software system of this size and complexity, we had a very smooth go-live experience. This is thanks to the dedication of staff in every department of the library.
After going online
After go-live, we focused on maintaining employee morale and making sure all user-facing features were functioning properly. We understand, accept and communicate that some employee functions will be affected as a result of our system cuts. For example, after going live, service technicians reported that their productivity was about 20%. A few weeks later, that percentage rose to 40%. We expect that the remaining two FOLIO versions this year will have a dramatic increase in functionality and productivity.
We track all bugs and feature defects on a Known Issues and Status Confluence page, accessible to all staff, to continue to maintain transparency. The implementation team is being reduced but continues to hold weekly meetings for staff to ask questions about FOLIO. Our Cornell Libraries Slack channel has become a vibrant place for library staff to post questions and receive help from colleagues.
The main points we reflected on the implementation process after going live are: the importance of transparent communication, the importance of flexibility and iteration, and the value of involving all employees in the process.
As of November 2021, Cornell is still running FOLIO Iris, the version we launched in July. If the test shows that there are no critical functional bugs, we will upgrade to future versions of FOLIO.
Sustainability of open source library platforms
Simeon Warner, associate dean for information technology at the University Library, said community support and collaboration are more important than ever for libraries, especially when it comes to sharing their growing electronic resources. “It’s important to realize that libraries like Cornell never operate alone,” he said. “Now, FOLIO provides us with a foundation to move forward in a collaborative way as libraries—which makes People are excited.”
As FOLIO grows and evolves with us, we may never migrate to another ILS.
About the author:
Jenn Colt is the director of technical services automation and metadata systems at Cornell University Libraries. She has worked in the library for more than 15 years in various IT and metadata roles. She has long been committed to improving user discovery capabilities and Make the open source software community more attractive to users.
Debra Howell is the Director of IT Operations at Cornell University University Libraries with more than 20 years of experience in project management and strategic direction in all areas of information technology. She is a certified Project Management Professional (PMP), is the FOLIO Implementation Project Leader at Cornell University, is a certified trainer in the Office of the Secretary of Defense, and serves as the information officer for the Women's Network Council of the American Council on Education in New York State.
END