By Wilhelmina Randtke

History of Georgia and Georgia Southern University Libraries Cataloging, Circulation, and the ILS/LSP

2017 Merger of Two Universities, and Migration from Voyager to Alma

In 2017, two separate events, each requiring a “big lift” occurred simultaneously. (1) In late May 2017, the Georgia Library Learning Online (GaLiLeO) Interconnected Libraries (GIL) consortium, of which the University Libraries is a member, went live fully on Alma following an approximately two year statewide migration from Voyager to Alma(GIL 2017[1]; GIL 2015[2]). (2) During 2017 the current Georgia Southern University and the University Libraries were formed by a merger of two predecessor institutions: Armstrong State University, located in Savannah and Hinesville, and the former Georgia Southern University, located in Statesboro. A January 2017 decision by the Georgia legislature merged Georgia Southern University and Armstrong State University, with merger occurring on short notice and completing fully in about 18 months (i.e. merger to fully complete in summer 2018) (Coleman 2017[3]).

ILS/LSP migration is a resource intensive effort. The Voyager to Alma migration was a two year effort (Lee and Frost 2017[4]). In January 2017, when the legislature required the merger of the two predecessor institutions, both predecessors were in the final stretch of migrating records and local workflows into Alma. Planning new unified workflows was not possible before Alma go-live. ILS/LSP migration tends to require additional intense configuration time, data cleaning, and communication during the six months to a year after go-live, as nuances arise in the real world (Ganz and Slavin 2024[5]; Nicholson and Tokoro 2021[6]; Rinna and Swierenga 2020[7]). Organizational mergers tend to be emotional and demoralizing following the merger for employees involved and productivity tends to drop in part because employees are distracted by the merger (Heidari-Robinson and Heywood 2016[8]).

Merger within an ILS/LSP involves integrating workflows, shared interface design decisions for the end user discovery interface, and metadata integration (FLVC 2014[9]). The ILS/LSP merger was not fully planned and implemented during 2017 nor 2018. All records from predecessor institutions were moved into the same instance of Alma, but cohesive workflows and metadata standards were not set up. Essentially each effort – migration and merger – competed for resources and employee bandwidth.

Additionally, unifying settings, for example, doing things like standardizing checkout times across campuses, was untenable mid-semester on short notice due to the necessity of communicating changes in checkout times to patrons ahead of time. In January 2017, when the merger was announced, each library had different checkout times for various kinds of materials. At the time of the May 2017 Alma go live, it was practically a necessity to maintain separate metadata practices and separate workflows within the same ILS/LSP in order to provide continuity and a good experience to patrons.

During the merger period for the campuses, the organizational structure of the University Libraries also merged. The University Libraries is one organization, reporting to one director. While some library systems might have independent libraries using the same Alma instance, for example, a law library and a main campus library where the accreditation standards require multiple libraries on campus to operate with administrative separation, no such arrangement exists at the University Libraries. This is important, because refactoring at the University Libraries involved eliminating settings within Alma which had been built out at the library level and moving those settings to the institutional level. For an Alma instance serving libraries with a different organizational structure, keeping settings at the library level within the ILS/LSP might make sense.

The Near-Universal MARC Standard for Discovery Oriented Metadata Aids Cohesive Interface Design, but Does Not Support Cohesive Workflows Nor Standardized Item Level Metadata

The MARC standard is well defined and detailed with regard to creating records at the bibliographic level (Library of Congress 2024[10]). Additionally, copy cataloging of bibliographic records ensures consistent quality and very similar or even identical bibliographic records will exist at different institutions (Chan and Salaba 2023 p. 41[11]). In the GaLiLeO consortium, during the 2015 to 2017 Voyager to Alma migration, the consortium had engaged in a process to attach items at all 28 member institutions of GIL to the same bibliographic record when copies of that item were held at multiple member institutions (Lee and Frost 2017[12]). That process meant that the vast majority of bibliographic level records at the two predecessor institutions had already been standardized through state-level activity before the legislature decided on merger.

At the item level, the MARC standard has far less detail. The MARC standard has extensive specifications (specs) for the bibliographic, authority, and holdings level records, but has no corresponding spec for item level records (Library of Congress 2023[13]). Only a few fields of the MARC standards, standards 876-878 describing item information stored in holdings records, describe item level metadata (Library of Congress 2008[14]). MARC also was designed with discovery in mind. At the time when the MARC standard was developed, MARC was intended to allow someone to remotely search collections at other libraries, in order to plan a visit or to efficiently place an interlibrary loan request. It was not designed with inventory or workflow as the primary focus, but rather designed with end user discovery as the primary focus (McCallum 2002[15]).

Interface design decisions for discovery were fundamentally supported by the MARC standard, and by statewide consortial activity, even before the merger. The vast majority of academic libraries use the MARC standard (Moehrle 2012[16]) and employees working in cataloging share a descriptive metadata standard for bibliographic and holdings records. In contrast, cohesive item level metadata is not defined by any near universal standard nor training, and item level metadata would tend to vary significantly from library-to-library.

The Georgia Consortial Environment Includes Specialized Features Focused on Discovery Interface, but Does Not Include Centralized Shared Workflows (Although Other Consortia Do Use Centralized Shared Workflows)

Georgia Southern University is part of the University System of Georgia (USG). In Georgia, all institutions of public higher education use the same ILS/LSP software which is procured statewide through the GIL consortium. Some configuration decisions are made at the statewide level through a GIL committee structure. Specialized features in a consortial ILS/LSP might support unmediated borrowing services between members and discovery and delivery of shared electronic resource purchases (FALSC 2018 p. 17[17]), which relate directly to end user discovery. Leading up to and after Alma go-live, the GIL OPAC/Discovery Committee had made collective decisions regarding many of the facets and behavior in the discovery layer. Primo at time of go-live, then later Primo VE, was the discovery tool bundled with Alma in the statewide contract for ILS/LSP purchase, and Primo / Primo VE settings were determined by the statewide committee. All discovery tool interfaces for all members had to be compatible in that all member discovery interfaces included an option to both search just that institution or all member institutions at once (see Figure 1).

Figure 1. Drop down menu on the University Libraries’ discovery tool interface and public search. A user to can search the holdings of the entire USG. For the past 10 years, the GIL OPAC/Discovery Committee has consistently made statewide configuration decisions regarding interface design for end users.

Additional specialized features in a consortial ILS/LSP which relate to shared workflows might include identification of the last copy of a print book, and centralized coordination of library employee user account permissions (FALSC 2018[18]). In particular, a consortium might have a shared manual for consortially acquired software and might have preconfigured user roles in the software to allow employees to follow the shared workflows. The GIL consortium did not operate in this way during the 2015-2017 period and historically has not operated this way, and so circulation workflows and local metadata practices were highly variable from member library to member library when predecessor institutions merged to form the University Libraries.

How Circulation Behavior Works in the Alma ILS

Physical Collections vs Electronic Acquisitions

This article covers refactoring Alma settings in the context of circulation logic rules for physical items. While digital materials have become an increasingly important part of library resources relative to print in recent years (Goek 2024[19]), physical items are key to the University Libraries operations and mission. Physical items include Special Collections materials such as personal archives, letters, local history items, and unique items. The University Libraries may be the only place someone can access a Special Collections item at all, and those materials tend to support research into institutional and regional history. Equipment such as graphing calculators and laptops experience extremely high usage, with laptops continuously checked in and out throughout the year. Additionally, laptop and equipment checkout supports student success in academics by bridging gaps in technology access for students waiting to finance a replacement for a broken personal device, or who may have left a personal device at home on a mostly commuter campus (Gonzales et al. 2020[20]; Wilmoth 2015[21]; Bell 2022[22]).

While acquisitions and collections as a whole are moving to digital with a reduced percentage of collections as physical items, the remaining physical items are of vital importance. Additionally, while electronic resource packages may come with records to be batch loaded (i.e. somewhat standardized), item level records for physical items are likely to be created and managed fully in-house. With metadata at the item level created and managed fully in-house, workflows for physical items are not streamlined by the wider library ecosystem.

Because of this, this article focuses on refactoring settings for physical items and circulation behavior.

Physical Item Circulation in Alma

In Alma, each physical item has a Location. Locations are grouped into Fulfillment Units (FUs), and a Location can be part of one and only one FU. Circulation logic rules are built out in the software for each FU, and circulation logic rules within one FU do not impact circulation logic rules within any other FU. Each circulation logic rule points at a Terms of Use, and a Terms of Use sets the detailed circulation behavior for that loan. The circulation logic rules can look at the User Group of the patron seeking to checkout the item plus any of the following fields on an item: Location, Material Type[Footnote 1], or Item Policy. FU, Material Type, Item Policy, and Terms of Use are settings defined purely within the Alma software and not part of the MARC standard. Alma includes a predefined list of Material Types and is not fully customizable. For Item Policy and Terms of Use, Alma is fully customizable. A library using Alma can edit a table in the software and create any number of Item Policies or Terms of Use.

Essentially, Alma determines circulation behavior based on logic rules which can attach to:

• Patron’s User Group.
• Item’s Location.
• Item’s Material Type.
• Item’s Item Policy.

Reducing complexity in the circulation rules can be done in three ways: (1) By configuring logic rules to not consider certain fields, for example, to not consider Material Type, (2) by reducing the number of values in use for any of the fields, for example, by reducing the number of User Groups patrons might be assigned to, and (3) by reducing the number of Terms of Use referenced by circulation logic rules.

In contrast to Alma, the predecessor system in use in GIL and at the University Libraries, Voyager, had based circulation on Item Type, a Voyager field which was split to two fields in Alma – Material Type and Item Policy (ExLibris 2024[23]). Alma allows more complexity, regarding metadata fields which can be made to impact circulation behavior, than did the predecessor ILS/LSP in use in Georgia.

The Need for Refactoring: Unexplainable Software Settings

In 2017, the year of both the Voyager to Alma migration and the merger of the two predecessor institutions, essentially each effort – merger and migration – distracted from the other, and as a result merger within the ILS/LSP was not accomplished regarding item metadata and workflows. In 2017, mismatched metadata and circulation rules were put into place within a shared ILS/LSP, with former Georgia Southern University locations having a different set of Locations, Material Types, and Item Policies and different circulation logic rules within Alma compared to those in use at former Armstrong State University locations. In general, within the ILS/LSP, settings in use exclusively at former Armstrong State University locations had names with “_LL” appended to the end of the setting name. And, in general, a setting without “_LL” appended to the end of the setting name, would work only at former pre-merger Georgia Southern University locations. (Lane Library with initials “LL” is the former Armstrong State University main library, located in Savannah.) The Locations belonging to predecessor institutions were fully separated into different FUs.

Alma allows settings to be built out at a library-only level. The University Libraries sometimes built settings out at the institutional level and sometimes at the library level. Balance between and workflows for coordinating the institutional settings and library settings were encountered late in the migration and close to go-live on the new ILS/LSP, with such a short notice for merger.

Merger, like migration, is a multiyear and stressful process in terms of truly merging to a new organization beyond the org chart (Heidari-Robinson and Heywood 2016[24]). Within the University Libraries, Cataloging was not merged until 2020, ILS/LSP systems administration was not brought primarily into one department within the University Libraries until 2021, and circulation desks are still separate departments within the University Libraries. This meant that as employees came and went, a new employee had no comprehensive explanation of software settings. Problems with numerous undocumented settings grew over time, as new employees, particularly in reserves, came on board, did not have comprehensive documentation, and requested new behaviors be built out within Alma which duplicated existing but undocumented behavior. Meanwhile, making changes to circulation behavior, for example, changing the checkout times or requestability of a specific kind of item or specific collection, required either analyzing increasingly baroque metadata and logic rules settings, or building out a new setting. In general, complexity of logic rules had ballooned such that building out a new and very specific logic rule was the only practical way to accomplish a change in a reasonable amount of time, which meant that even small changes to workflows were likely to cause additional bloat to settings.

Between the 2017 go-live on Alma and 2024, circulation behavior for physical items had gradually been brought into alignment. This process generally had been accomplished by layering logic rules for narrow carve outs. It was common for circulation logic rules to reference very specific combinations of Location and Material Type. This tended to cause problems for items assigned less-used Material Types, which had not yet been accounted for. When a problem was identified, it might be addressed using yet another circulation logic rule with a narrow carve out, because comprehensive behavior was too baroque to address without extensive time analyzing existing circulation logic rules. Going into 2024 there were around 17 FUs in use for active library collections, each with dramatically different circulation logic rules, such that comprehensively implementing a change to circulation behavior required analyzing circulation logic rules for all 17 FUs. As a result, changes to checkout behavior could not be implemented in a reasonable timeframe. Time which should have been spent on the “handshake” of communication between Libraries Systems and Technologies (Systems), Cataloging, and checkout desks was instead spent on Systems and Cataloging looking at overly complicated settings and on employees at checkout desks reporting problems.

At the start of 2024, settings across the 17 active FUs in the University Libraries’ Alma instance had been built out to include: 33 User Groups x 135 Locations x 75 Material Types x 121 Item Policies = 40,429,125 possible permutations of metadata settings which could impact circulation behavior. Meanwhile, the University Libraries had a little over 1,000,000 physical items including both traditional library media like books and microform, as well as reserves and equipment! With 135 Locations x 75 Material Types x 121 Item Policies = 1,225,125 permutations of metadata settings on an item, there were more possible combinations of settings than there were items, and it would have been faster to assess and assign desired behavior one-item-at-a-time than one-permutation-at-a-time.

At the start of 2024, there were approximately 1,200 permutations of Material Type, Item Policy, and Location actually occurring on items in the University Libraries’ instance of Alma x 33 User Groups in use = 39,000 permutations of settings affecting circulation behavior actually in use within Alma. At that time, circulation logic rules used all four metadata fields.

The 1,200 permutations of item metadata actually in use in Alma was a good number for having internal conversations about a shared goal of software explainability. 1,200 is a number people can visualize. 1,200 was also still too many combinations for University Libraries employees to meet about and decide how circulation should work for each.

Going into 2024, employees across the University Libraries were frustrated with the state of circulation rules. Bloated item level metadata settings and logic rules for circulation had led to regular encounters with apparently chaotic behavior in the ILS/LSP. Cataloging, which created item records on a daily basis, had centralized notes about settings for item level materials in open stacks, but generally had no explanation of how reserves and equipment items worked. It was common for employees at a checkout desk adding a new reserves item to change settings on the item several times, and then to open a ticket with either Cataloging or Systems to “fix” the item because they had not been able to achieve a desired checkout behavior. Systems felt obligated to provide instructions on how to use the software, while simultaneously realizing that the settings were not explainable.

Early in the merger, there had been real differences in intended circulation behavior for various kinds of library materials between the two campuses. By 2024, the University Libraries had generally brought circulation behavior into alignment by layering logic rules onto non-unified metadata. As a result circulation logic rules and metadata tended to be highly variable from campus to campus. Close to merger in 2017, the issue at hand had been the need to meet and make shared decisions to determine shared behavior was for circulation. By 2024, the barrier truly was the software settings.

Steps in Refactoring Alma

Step 1: Infrastructure for Versioning Changes

Implementing Basic Infrastructure: Naming Conventions to Allow Versioning of Circulation Logic Rules within Alma

Modern software tends to be versioned. Using Git or Subversion (SVN) is nearly universal for versioning even simple software. When software behavior is built out through settings in a content management system, the wider coding community has tools for versioning settings. YAML is a language for representing configuration settings which allows importing and exporting configuration settings. YAML can be combined with version control, such as git, to allow versioning of configuration settings (Red Hat 2023[25]).

Alma doesn’t have a comprehensive way for customers to export settings. Typically, within Alma, when looking at a specific kind of configuration setting, there will be an export button in the top right of various settings menus allowing an export, and when there is such an export button, that same export may also be available by calls through the Alma application programming interface (API). However not all configuration settings can be exported, and an export allowed from Alma may be incomplete in that it may omit important information. In the case of circulation rules within Alma, the export includes the letter code, description, and name of the outcome (i.e. name of the Terms of Use) of each logic rule. The export does not include the logic to get to that outcome. Instead, getting that information requires clicking into each logic rule.

Figure 2. Screenshot of the Alma page where a circulation logic rules overview is displayed for a FU. This screenshot was taken after implementing a naming convention for the output (Terms of Use) and for the Description of each logic rule. Those are labels only. The software behavior is built out by clicking into each logic rule.

Figure 3. Screenshot of the graphical interface for building out a single circulation logic rule from Figure 2. Each circulation logic rule requires clicking into the rule in order to see settings. The Description field is manually written by Systems employees, not used by Alma, and nothing in the software keeps it in sync with the actual software settings.

Figure 4. Screenshot of an export from Alma to Microsoft Excel. The export includes exact values shown in the overview menu. The University Libraries used a standardized naming convention to represent the logic of each rule.

In order to do a comprehensive clean up, the University Libraries needed to have a reliable way to version settings. To achieve versioning, the University Libraries developed a naming convention for the description field of the Alma circulation rules. The naming convention for the Description field of each circulation logic rule is shown in screenshots above. The Description field was edited to include: (1) indication of which item metadata fields were used by that role, followed by (2) pseudo code representation of the actual logic rules.

First, at the very start of the description, in brackets, is the initial of any item level metadata fields used by the logic rule. If that item metadata field is used, then the initials are listed. For example, “[MT]” would be the start of a Description for a logic rule which references Material Type in the logic. For example, “[IP]” indicates the logic rule references Item Policy. For example, ‘“[Loc]” indicates the logic rule references Location. For example, “[IP,MT]” indicates the logic rule references both Material Type and Item Policy. If no item metadata fields are referenced, then the start of the Description for that logic rule would read “[NULL]”. During refactoring, the University Libraries phased out use of Material Type and Location in logic rules. Because of this, noting what item metadata fields were used prominently and upfront in the naming convention assisted in identifying settings to be phased out, versus settings to be retained and refined. Depending on what spec / big picture design a library is working towards, a library might wish to emphasize different fields.

Second, the remaining Description field was filled with text reading “[RULES: ” followed by a list of each parameter of that logic rule. User Groups was listed first as “User=” and then the list of User Groups that rule applied to. (After behavior was streamlined to treat bundles of User Groups similarly, names of User Groups were phased out, and only the letter of each bundle was listed.) If no User Group was listed in a logic rule, then the “User=” part was omitted. Following that came “IP=” followed by any Item Policies referenced in that logic rule. Following that came “Loc=” followed by any Locations referenced in that logic rule. Following that came “MT=” followed by any Material Types referenced in the logic rules.

After the naming convention was fully implemented in all FUs, the University Libraries used the Excel export within Alma to comprehensively export rule names and descriptions, copy paste all logic rules for all FUs into a single large spreadsheet, and then have a record of what the logic rules had been at a specific time.

Figure 5. Screenshot of the spreadsheet showing the June 2024 state of all FUs and their circulation logic rules. The spreadsheet continues vertically offscreen and includes a section for each FU including the Loan, Booking, and Request rules for each.

With the spreadsheet of comprehensive rules on file, the University Libraries could later export a current report of settings for any FU and then used diff to compare the rows for that setting against the most recent comprehensive export. Websites like https://www.diffchecker.com/ allow quickly comparing two text files and will highlight additions and deletions. During the refactoring process, the University Libraries pulled a fresh comprehensive spreadsheet approximately monthly, and kept all comprehensive spreadsheets in a shared folder in Google Drive. This allowed later retracing steps, if needed, and allowed answering questions. During the refactoring process, employees at checkout desks were told to look out for odd behavior and report problems. During the early weeks of refactoring, it was routine for employees at checkout desks to report preexisting odd behavior. The spreadsheets of past circulation logic rules were helpful in confirming times when Systems had not introduced new problems, and to isolate and quickly correct any problems inadvertently caused during the refactoring process. For reference, initially, with approximately 17 FUs in use at the start of the refactoring, exporting logic rules from all FUs and putting them into a single comprehensive spreadsheet took around an hour.

Figure 6. DiffChecker report comparing the 2024 June vs the 2024 August spreadsheet with comprehensive reports of all FU circulation logic rules. Diff is a common data comparison tool, and many different software packages and operating systems can be used to diff two text files.

The naming convention had two immediate benefits. First rules could be versioned. Versioning allowed rolling back to a previous state, if needed, which helped to prevent downtime in the case of accidentally introducing problems. Second, versioning led to improved communication. Versioning is a passive form of communication between computer programmers, and with a versioning process established and agreed on, multiple employees could edit the circulation logic rules and keep shared notes. This allowed cross training within Systems. The naming convention enabled employees in technical roles to quickly see and understand the circulation logic rules and have a conversation on the fly oriented around the spreadsheet and without extensive preparation before a meeting to familiarize with a specific FU’s logic rules. This enabled smooth on-demand conversations within Systems and between Systems, Cataloging, and employees working with checkout.

Naming Convention for Terms of Use

Each Terms of Use is built out within the Alma software by the customer and is highly customizable, containing the exact outcome behavior of a checkout (whether an item is requestable, how long a loan is, what happens when a loan due time falls during a library closure, etc. (ExLibris 2025)). Terms of Use can exist at the institutional level or the library level within Alma. Another nuance which can make Terms of Use harder to document is that a Terms of Use will apply to either Loans, Booking, or Request. Multiple Terms of Use can have identical names. Before refactoring, there were multiple Terms of Use with identical names. When building out a circulation logic rule, and using the drop down menu to select the Terms of Use, the only setting which shows is the name of the Terms of Use. To quickly differentiate Terms of Use, the University Libraries labeled the Name of each Terms of Use with a bracketed note at the end stating whether the rule existed at the library vs institutional level, and whether it applied to Loans vs Booking vs Request. For an institutional level Loan Terms of Use, “[Inst., Loan]” was appended to the Terms of Use name. For a library level Terms of Use, “Inst.” was replaced with the name of the library. For example, a Terms of Use in existence at the Lane Library level within Alma and applicable to Request had “[Lane, Req]” appended to the name of the Terms of Use.

This naming convention had three benefits: (1) It completed the naming convention for the circulation logic rules described above, and allowed versioning (see output column in Figures 2 and 5); (2) A goal in refactoring was to eliminate settings built out at the library level, and this assisted in identifying which Terms of Use existed at the library level, and (3) in the early stages of refactoring standardized naming assisted in locating the details of each Terms of Use within Alma’s configuration area.

Data Dictionary for Later Reference

Logic rules for circulation behavior in Alma can reference patron’s User Group, or item’s Material Type, Location, or Item Policy in order to determine software behavior for circulation. Before refactoring, the University Libraries anticipated dramatic changes to those fields. A data dictionary is a “centralized repository containing information of the data in the database such that the meaning, relationship, source of the data, where it will be used and the format is clearly mentioned or specified” (McDaniel 1994[26]). Because of anticipated dramatic changes to those four fields, before changing settings, the University Libraries documented existing constraints on settings for each of these fields with a data dictionary for those fields.

In general, Alma’s configuration area has a table for seeing what User Groups have been created, what Material Types are enabled, what Locations exist at each physical library, and what Item Policies have been created. When viewing each of these tables in the configuration area of Alma, it’s possible to click a button in the top right corner to export a spreadsheet of that table. There are also instructions for exporting these settings by Alma API posted to https://developers.exlibrisgroup.com/alma/apis/conf/ . The University Libraries exported each table representing all settings, and copy pasted all tables together in a single Google Doc file. The University Libraries labeled each table, and an introduction to the data dictionary explained that the purpose of the data dictionary was to document settings before streamlining them, in case of having to retrace or having to reference the information later. Exporting the settings was a one time process for the pre-refactoring data dictionary and exporting through the user interface was the most straightforward way to get a one-time export. Naming conventions were implemented before assembling the data dictionary. The most important information is not inherently included in the export, but rather has to be added with a labeling convention or other way of recording setting-by-setting notes.

Regarding Terms of Use, the University Libraries exported the detailed outcomes of each Terms of Use which was in use anywhere on the Alma site, and added each as a separate table in the data dictionary. This allowed retracing steps as Terms of Use were consolidated and less-used or library-level Terms of Use were eliminated. Because Alma allows multiple Terms of Use to have identical names, the naming convention was implemented and names were made to be unique before exporting each to the data dictionary. Only Terms of Use which were actually referenced by circulation logic rules were exported to the data dictionary.

In addition to allowing retracing steps during refactoring, the data dictionary allows later inspection of Alma Analytics reports, for example, Association of College and Research Libraries (ACRL) Academic Library Trends and Statistics Survey survey reports and Integrated Postsecondary Education Data System (IPEDS) reports. After refactoring and dramatic changes to settings, if a setting which had been used in an Alma Analytics report is found to be impacted or broken by changes, it is possible to refer back to the data dictionary and see what the change was which had broken that report. In some cases, pulling a report after clean up might require temporarily recreating a setting within Alma, and the data dictionary allows recreating the setting if needed.

While eliminating settings, Systems looked at whether deleting the setting within Alma would alter a statistical report. This included looking at Alma Analytics, and at Panorama, a statistical program which can accept exports of Alma data and in which the University Libraries’ historic Alma data will be stored in long term. Deleting settings from the configuration area of Alma does not tend to cause trouble with day-to-day behavior within Alma, but can cause problems with statistical reports.

Step 2: Writing a Written Spec for Software Behavior

In Spring 2023, no comprehensive standard for how circulation should work in Alma existed. A public webpage explained checkout behavior to patrons by giving checkout times for books in the stacks, audiobooks in the stacks (a genre which had been almost fully weeded with a shift to streaming content for audiobooks), and for DVDs, for a handful of demographics of patrons. Patrons were instructed to contact each checkout desk separately for information about checkout times and availability of other materials.

A reason which necessitates refactoring might be that software might tend to initially be designed, and then over time to have small edits made to implement new features, and those edits be made without the big picture design in mind. Refactoring can bring the overall software back to the big picture design. Design patterns provide targets for refactorings and refactoring can bring software back into alignment with the overall software design (Fowler and Beck 2018[27]). In order to bring software into alignment with overall design, the University Libraries first documented the overall design.

Technical Framework

At the University Libraries, Systems planned to structure circulation behavior on three metadata fields:

• Patron’s User Group
• Item’s Location
• Item’s Item Policy

Material Type would not be used, because it acted as a description of the item, and so was felt to have descriptive truth as to what the item was. Alma’s controlled vocabulary for item Material Types includes a code and description for each Material Type. Descriptions are terms like “Book”, “CD (Audiobook)”, “Blu-Ray Disc”, and “Film 16mm”. Values were not configurable in that the description could be changed but the code could not, and the list of Material Types could not be added to. The descriptive nature was hard coded into Alma.

Location would be used to designate specific locations as noncirculating. Then within circulating locations, Item Policy would determine circulation behavior for each User Group.

Before refactoring, noncirculating Locations were generally already grouped into the same noncirculating FUs within Alma. No clean up of metadata was needed to account for noncirculating locations, and conceptually, according to the spec, any Location in Alma would have one of two behaviors for purposes of circulation behavior: Either noncirculating or circulating.

Regarding User Groups, the University Libraries eliminated the least used of these and grouped the remaining User Groups into bundles. User Groups with very few members or with many members all of who were expired were eliminated. Members were migrated into the closest User Group. For example, multiple community colleges in the region had User Groups in the University Libraries’ Alma, with accounts created ad hoc and just a handful of accounts in each. Patrons from all community college User Groups were moved to the “Community” User Groups for public patrons. Once empty, User Groups were not deleted in Alma, because this would impact ability to pull statistics by obscuring User Group information in statistics.

Posted circulation times on a public facing website addressed open stacks materials availability to current undergraduate students, current graduate students, faculty and staff, and community members. Additionally, the GIL consortium operates GIL Express, shared print borrowing, with standardized loan times for all materials (GIL 2025), representing a fifth clearly defined User Group. Within Alma, these User Groups tended to be accounted for and referenced within existing logic rules for circulation, while other User Groups might be haphazardly referenced, or not referenced at all. Because of this, those five groups were taken as the starting point for narrowing User Groups into bundles, and each bundle was labeled with a letter. The core User Groups for defining behavior were:

• (A) GaSoU Students
• (B) GaSoU Graduate Student
• (C) GaSoU Faculty/Staff
• (D) Community
• (E) USG GIL Express Patron

For other User Groups which were to be retained long term, Systems made a recommendation as to which letter to bundle that User Group along with, and then presented the recommendation to the University Libraries’ Dean’s Advisory Council, consisting of University Libraries department heads, and to the Collection Development Committee (CDC). Based on this, User Groups to be retained were bundled into five bundles, and each User Group was renamed with a letter for that bundle. For example, the (A) User Groups are:

• (A) GaSoU Students
• (A) GHP Fac & Staff
• (A) East Georgia Students
• (A) Medical College of GA Students

Individual User Groups were retained long term. Batch load processes for adding users to existing User Group were kept in place. Pulling up a patron record and seeing the User Group tells something about that patron and what their relationship to the University Libraries is. Patrons were not moved all into only five User Groups, but rather, each User Group was renamed to start with (A), (B), (C), (D), or (E), and all User Groups starting with (A) were to have identical circulation privileges as one another. Ultimately, 13 User Groups were retained, and were grouped together into five bundles each with identical circulation behavior.

Bundling User Groups and lettering them both aided conversations about how circulation worked by limiting the complexity of checkout behavior decisions to a smaller number of conceptual groups of patrons, and aided in comprehensively accounting for all User Groups within Alma. Alma circulation logic rules are built out in a graphical user interface which sorts User Groups alphabetically. Bundling and lettering the User Groups makes it fast to quickly add the correct User Groups when editing a logic rule, because all User Groups starting with “(A)” will display together when building out a rule (see Figure 7).

Figure 7. Screenshot of the graphical interface for building out a circulation logic rule. When adding User Groups as a parameter, Alma displays an alphabetical list of User Groups. After implementing the naming convention, all User Groups starting with “(A)” sort together, and it is fast and easy to pull all up and add all at the same time. It is also obvious if one User Group in that lettered bundle of User Groups has been omitted.

Within Alma, Item Policy is fully configurable. An editable table within Alma defines the code and the description. An Item Policy can have a code or description which is descriptive of time frames, such as “1 week, renewable”, something abstract, such as “cotton candy”, or something descriptive of the item, such as “book”. Before refactoring, within the University Libraries’ Alma, the Item Policy descriptions which show in the drop down menu while editing an item tended to either describe the item (i.e. “book”) or to give a timeframe (i.e. “4 hours”). As purely a software construct and configurable in such a way that it does not have to be descriptive, Item Policy is a better fit for software behavior than are the descriptive metadata fields. Additionally, when software problems were reported to Systems, if an Item Policy stated a timeframe, such as “1 week”, “2 hours”, “4 hours”, etc. and checkout time was different, the discrepancy tended to get reported as a problem. Employees across the University Libraries had difficulty understanding that Location or Material Type could impact circulation behavior, and tended to want Item Policy to control the behavior if they saw a label stating a timeframe. Because of this tendency of University Libraries employees to orient conversations about problem behavior around the human readable Item Policy description, moving circulation behavior to work off of Item Policy for circulating locations was in line with getting the software to work in the way that people already expected it to work.

Motivating Employees Across the Libraries

Going into 2024, there were 121 Item Policies built out in the Item Policy table in Alma. This was too many to define behavior for, and too many to summarize concisely. This was also a source of daily aggravation for employees working with item level metadata. When editing an item, Item Policy is added and edited using a drop down menu. 121 options was too many to easily view all at one time in a drop down menu. Aggravation with the drop down menu and a shared goal of shortening it was a motivator early on in refactoring.

At the start of refactoring, Systems ran reports in Alma Analytics to identify less used Item Policies. Several Item Policies were applied only to items in withdrawn locations. (Items which are withdrawn at the University Libraries are cataloged to a withdrawn location in the software which allows for later auditing regarding disposal of state property, and other recordkeeping.) The University Libraries initially created a new Item Policy, “Withdrawn”, batch changed the Item Policy on all item records in withdrawn locations to be “Withdrawn”, and then deleted Item Policies which were no longer assigned to any item from the Alma Item Policy table. This reduced the Item Policy drop down to around 80 options. This had a motivational effect, as employees working with item level metadata noticed a shorter drop down, and as all removed options were options had been applied to long gone items and were not in use in anyone’s workflows.

Systems then analyzed remaining Item Policies. A trend, which had occurred in reserves was that with employee turn over, a new employee would not have notes as to how settings worked and would request a new behavior be created in the software. Systems didn’t have notes as to how settings worked and would implement by building out new settings, rather than editing existing settings. As a result, many Item Policies appeared to have duplicative intent. There were several settings like “OvernightLL”, “1 Day Reserve”, “Next Day” which all seemed to indicate the same intent of a one day checkout. There were settings for “1 Week Reserve”, “1 Week – no Renewals”, and “7-Night Reserve_LL” which all seemed to indicate the same intent. Similarly, the Item Policies ending with “_LL” tended to each have a corresponding Item Policy without “_LL”. Numerous Item Policies matched with a smaller number of desired outcomes for checkout behavior. Existing software settings for Item Policy were repetitive and chaotic. Because of this, existing software settings were not included in documents shown to focus groups when writing the spec about how Alma should work.

Figure 8. View of the Item Policy drop down menu when editing an item in Alma taken before refactoring. Note the scroll bar along the right hand side of the drop down menu. Going into 2024, and before refactoring, there were 121 options in the drop down menu – too many options for a drop down and better suited to an autofill field. While the screenshot only shows settings beginning with numbers, which tend to be time periods, numerous other settings for Item Policy were labeled things like “DVD” and “Book_LL” (i.e. abstract words inviting dramatically different interpretation for behavior).

In order to define a set of intended behaviors for the spec, a series of focus groups were held. Rather than orienting conversation around software settings, Systems oriented focus groups around a human readable description of how long the checkout period was supposed to be for each combination of User Group letter bundle and each kind of material circulated. Focus group documents were largely platform agnostic, and could have been used to establish goals for any ILS/LSP, not limited to Alma. Most time was spent on checkout time. While circulation behavior is more complex than just checkout time, checkout time was simple enough to have a comprehensive conversation across kinds of items and patrons, and checkout time might tend to be the most important core behavior for a loan.

For stacks materials, Systems prepared a table of kinds of materials (i.e. books, periodicals, DVD movies, government documents), and how long each appeared to currently circulate to each bundle of User Groups (See Figure 9). Systems presented this to the CDC, and got any corrections there.

Figure 9. Screenshot of the document shown to the University Libraries CDC for approval and corrections as to big picture intent for behavior. An introduction to this focus group document went over how User Groups were bundled. While getting feedback, Systems might raise specific User Groups as appropriate.

Regarding items kept behind a checkout desk, Systems held a series of focus groups with the department heads over each of the three checkout desks. The first focus group was open ended brainstorming to identify every kind of circulating material (i.e. whiteboard markers, clickers, calculators, projectors, reserves options offered to professors placing items on course reserves). Each kind of thing circulated, equipment, reserves, etc. was added as a row to the bottom of the table in Figure 9. Then two focus groups were held to determine how long each kind of item was intended to circulate to each of the five bundles of User Groups. As desired checkout times for each item were finalized in discussion, that row was highlighted in green to note that all relevant stakeholders had agreed on the desired outcome.

When all desired checkout times had been agreed on for each kind of circulating material, Systems grouped desired outcomes. Thirteen groupings of checkout behaviors emerged organically.

With a goal of moving all circulation behavior to work off Item Policy, this meant 13 Item Policies would be defined in the spec. A goal had been to reduce to under 25 Item Policies, in order to meaningfully fit within the drop down menu displayed when editing an item in Alma, but there was no set number to reduce to. If more combinations had emerged, then more would have been included in the spec. In reducing to 13 Item Policies, Systems matched to existing Item Policies with preference given toward retaining Item Policies which tended to be assigned to more records. When an existing Item Policy had an abstract Description within Alma, such as “Standard”, “DVD”, or “Camera”, Systems renamed the Description within Alma to include both the abstract term and the amount of time it was checkoutable to undergraduate students (the most numerous patron group). In this way, all circulating Item Policies now appear in the Alma interface with a label saying how long that item will circulate to undergraduate students. In the future, the abstract portion of the Item Policy description will be removed. Hence, “DVD” was renamed to “DVD (1 week, renewable)” during refactoring, and in the future will be renamed to “1 week, renewable”. The purpose of retaining existing Item Policies was to avoid adding additional options to an already too-long dropdown menu. Reducing the number of options in the dropdown menu was a shared vision everyone working within the Alma software could understand, and throughout the refactoring, the gradually shrinking drop down menu and the reduced number of clicks in day-to-day work was a motivator for collective action. Incrementally changing names of Item Policies to be retained was to allow continuity in workflows and notes for anyone using those specific settings. After matching outcomes to Item Policies, Systems added the Item Policy for each kind of circulating thing to the original focus group document (See Figure 10).

Figure 10. Finalized table after completing focus groups showing goal big picture circulation behavior at the University Libraries for each kind of circulating item, and showing Item Policy to be applied in the rightmost column. After refactoring, this same chart could be used to go from real world what-the-item-is to a suggested Item Policy to assign in Alma.

Systems then conducted a focus group with the heads of each checkout desk to discuss detailed behavior for each Item Policy. Additional circulation behavior beyond checkout time and requestability included: whether a loan shortens or lengthens if the due date falls during a closure; grace periods; whether an item can be recalled while on loan; any limits on reloaning that same item to the same patron; time on the hold shelf before reshelving for requestable items; time overdue for the item to age to lost; and time after a return for checkout history to age off. This more detailed behavior was added at the end of the Google Doc containing the table in Figure 10, and is not reproduced in this article. The more detailed spec was rarely used as a communication tool for messaging about change, but rather was used by Systems to quickly know without additional conversation what was and wasn’t a bug if changes in nuanced behavior were reported during refactoring. Simplicity in the spec was achieved by limiting the number of options, in the form of fewer defined sets of behaviors, but not in the form of failing to account for settings for each set of behaviors. A small number of options were each defined comprehensively. Essentially, all items sharing the same checkout times for the same bundles of User Groups would also all have identical behavior in every other way. For example, all “1 Week, No Renewal” checkouts with a due date falling at a time when the library was closed would shorten to the closing time closest to closure. Complexity in software might inevitably be a result of complexity in the workflows which that software supports and complexity in the real world (Brooks 1987). Streamlining and unifying real world workflows in support of explainability was a key step in a unified software design to support streamlined, maintainable, and explainable software.

The written spec to work towards consisted of: 2 location behaviors x 5 chunks of User Groups x 13 Item Policies = 130 permutations of settings to account for.

130 permutations can be explained concisely. At this time, after completing the detailed spec, a LibGuide page with a concise explanation of checkout behavior in Alma was posted on the University Libraries intranet, with clear labeling stating that behavior was not yet set up. That is attached as Appendix A.

Step 3: Decide on a Test Procedure for Testing Changes

The University Libraries did not comprehensively test changes during refactoring, but rather looked at a threat model of which software bugs were acceptable to occur and fix later vs which were unacceptable. Systems tested only for unacceptable problems. Refactoring is a process of many small changes (Fowler and Beck 2018[28]). Meanwhile, comprehensively testing all aspects of software behavior is overly time consuming for a small change. Prior to refactoring, the circulation rules were so baroque that any change tended to have unintended consequences.

In developing a test procedure for testing changes, Systems considered a threat model of what problems could occur which would cause severe harm. This narrowed down to two potential severe problems.

First, Special Collections materials becoming requestable within the Alma software was a serious threat. The vast majority of Special Collections materials at the University Libraries are stored in a three storey high automated storage and retrieval system (AS/RS) high density storage facility, referred to as the Automated Retrieval Collection (ARC). For materials in the AS/RS / ARC which are requestable, patrons can request those directly through the public catalog. When a patron places a request, a computer at the circulation desk prints a slip with the item information on it, and a robot crane fetches the bin with that item in it and places it on a counter for a checkout desk employee to retrieve. Items are regularly retrieved by student workers fully under the supervision of the Henderson Library checkout desk and not under the supervision of Special Collections. While, at the time of install for the AS/RS / ARC, it would have been possible to physically separate access to ARC storage bins by putting in multiple counters on physically separated floors and tieing dedicated storage bins to specific counters, that was not done at the time of installation. Retrofitting for physical separation would be a massive construction project, and is not under consideration. As a result, software, specifically the request feature in the ILS/LSP, is the only barrier to prevent physical access to Special Collections materials. Due to apparent chaotic circulation behavior within Alma, going into 2024, student workers at the checkout desk serving the AS/RS / ARC all had permissions within Alma to override blocks on checkout. If a Special Collections item were to become requestable within Alma, and a patron were to place a request, a student worker at the checkout desk would be the only person in a position to catch the error.

The second serious harm which might occur is for a short term loan item, such as a highly in-demand laptop or graphing calculator or a reserves textbook to become checkoutable for either the standard 4 weeks with two automatic renewals for undergraduate students, or the semester long checkout with two automatic renewals for employees. In that case, the item could become unavailable to other patrons for an extended period of time.

Regarding Special Collections items in the AS/RS / ARC system, all were in the same three Locations within Alma. All locations were in a FU within Alma for noncirculating items, and so did not circulate and were not requestable based on location. Before changing settings within Alma, Systems met with the Special Collections Librarian, showed how to confirm whether or not an item was requestable within Alma, and identified a Special Collections item within each Alma Location. Systems explained the refactoring process and timeframe, then gave updates along the way. Systems built an Alma Analytics report to track checkouts of Special Collections items, and checked this periodically during and after the refactoring process. Systems also provided the Special Collections Librarian permissions within Alma and a written instruction sheet to allow her to confirm at any time that no Special Collections items were currently checked out.

Regarding short term loan items, when long term loan behavior was rolled out to reserves and equipment locations within Alma, Systems did additional metadata reports regarding items in Locations with mostly short term loans (i.e. reserves and equipment locations). If an item had a problematic setting (i.e. an Item Policy destined for long term loan behavior), Systems aggressively pursued getting the desired checkout time from the appropriate checkout desk and coordinated with Cataloging to ensure metadata was corrected before changing software settings.

Throughout the process, Systems examined each settings change for potential to impact requestability of Special Collections items, and potential for having a short term loan item go out on a long term checkout.

Step 4: Rolling Out Changes

The core of refactoring is making many small changes to code/settings, without changing the behavior of the software. Problems in software caused by refactoring should be minor and quickly fixable, due to the nature of changes as small and incremental (Fowler and Beck 2018[29]). The University Libraries operates nearly daily throughout the year, and the longest closure is a typically less than two week closure for winter break. Implementing dramatic change in one big sweep was not feasible nor compatible with daily year-round operations. Closing for six months to change logic rules, do metadata cleanup to match changes, and test all changes was not an option. Instead, changes went out weekly during Summer and Fall 2024. Implementing changes in small steps over a longer time period was beneficial in that problems tended to be easier to connect back to a specific change and to fix. Institutional will to complete the process was important, so that problems would be reported and collaboratively fixed, rather than treated as a reason to stop. Throughout the process, Systems communicated that checkout behavior was likely to break at time, and that the goal was for any problems to quickly be reported to Systems and fixed. The Dean of the University Libraries also got updates about the progress of settings cleanup and refactoring throughout 2024. During roll out for settings changes, minor problems occurred regularly and were quickly resolved. The kinds of problems that might occur were things like a 4 hour checkout item with a due time falling during overnight closure had the checkout time automatically extended to closing time the next day, rather than shortened to closing time the same day, as a result of changing away from a library level Terms of Use to the closest institutional level Terms of Use. When reported, that problem was investigated and fixed libraries-wide by referring to the detailed written spec which stakeholders had already approved before refactoring began.

Versioning

Internally, the University Libraries have an Alma LISTSERV. Any changes to Alma configuration settings are announced on the internal LISTSERV, with the idea that this allows later retracing steps. ExLibris provides an Alma test server and Alma production server to each customer. Data and settings from production are copied to test every six months, and so generally the test server includes a full copy of production data. At the University Libraries, refactoring involved settings changes, and metadata cleanup. All settings changes were made on the test server, announced on the internal LISTSERV, and then rolled out to the production server the next week. Initially, changes were made on production on Friday mornings, since Friday is the slowest day. Early in the refactoring project, this changed to a practice of moving settings changes to production on Mondays, on the theory that early in the week, more people in technical roles were at work and able to quickly route and fix any problems promptly. Metadata cleanup was done directly on the production server.

Before beginning refactoring, the naming scheme for circulation logic rules was rolled out to Alma test then production. All circulation logic rules, with a description which now fully described the logic within the rule, were exported to a spreadsheet. Approximately monthly throughout the project, the same process was repeated to allow viewing a relatively recent version of rules in a spreadsheet. As each logic rule or setting was changed, the email notification to the internal LISTSERV included a screenshot of the before and after of the logic rule. By looking at the most recent spreadsheet of settings and then the incremental changes messaged out to the internal LISTSERV, it was possible to know the state of the circulation logic rules on any given date.

Streamlining User Groups

During Spring 2024, the Systems rolled out changes to User Groups. Changes to User Groups settings consisted of changes the descriptive names of User Groups to add the letter designation (i.e. adding “(A)”, “(B)”, “(C)”, “(D)”, and “(E)” to each User Group name), and then working through existing logic rules for checkout and adding less used groups side by side with the more commonly used User Groups. For example, “(C) GaSoU Faculty/Staff” was almost universally set up to be able to check items out. Meanwhile, “(C) Emeriti Faculty” was referenced in only a few places. That was despite faculty handbook provisions guaranteeing emeritus faculty equal library privileges to current employees. Because there were relatively few emeritus faculty compared to current employees and to community members, problems with checkout occurred far more rarely, tended to have been fixed with an override rather than reported, and so checkout had never been comprehensively configured. Bundling the more heavily populated User Group together with the less populated User Groups together helps to ensure that any problems with configurations will be reported. Meanwhile, data cleaning was straightforward. Few patrons were moved to another group, but rather groups were renamed to include the letter designation.

Some of the less populated User Groups were emptied, and members moved into the User Groups which were to be retained. When a User Group was empty of patrons, the description of the User Group in Alma was edited to indicate that the User Group was empty and no longer in use. User Groups were not deleted out of Alma. Each User Group has a code and a description within Alma. By leaving the User Groups in the code table, the connection between code and description remained in place in case of looking at older statistical data.

Streamlining Circulation Logic Rules for Open Stacks Materials

During Summer 2024, open stacks materials were addressed. Regarding open stacks materials, at Lane Library, many had legacy settings for the Item Policy including “_LL” in the name. Prior to refactoring, circulation logic rules at all relevant FUs rarely referenced Item Policies in determining checkout times of materials, but rather referenced combinations of Location and Material Type. Over Summer 2024, Cataloging did batch changes to eliminate the numerous “_LL” Item Policies in the open stacks and ARC, and to replace them with Item Policies which would be retained. After batch changes, Systems changed circulation logic rules for circulating stacks and ARC FUs to now work off Item Policy. Because this was a massive amount of changes to item records, changes were planned in such a way as to not be time sensitive. Systems checked over circulation logic rules, opened a ticket with Cataloging to do a specific batch change, Cataloging could make the change time allowing (turnaround time might be promptly or could be months later), and then Systems finalized circulation logic rules and deleted the now unused Item Policy out of the table in Alma.

During Fall 2024, Systems comprehensively rolled out Item Policies to all circulating locations. With 13 Item Policies to roll out, comprehensively rolling out Item Policies took around 14 weeks. Each Item Policy was built out first on a single FU. Generally that was a FU which included Locations which had many items with that Item Policy applied. That was done ahead of time by several weeks. Then during the Fall 2024 semester, one Item Policy per week was rolled out comprehensively to all circulating FUs at the University Libraries. Roll out meant that that Item Policy was built out identically on all circulating FUs using the exact same circulation logic rules and pointing to the exact same Terms of Use. Alma reads circulation logic rules top to bottom for each FU, and applies the first matching rule to a loan. Each newly launched logic rule was sorted early in the list of existing logic rules, such that existing logic rules remained in place as a fall back during the refactoring process.

During Fall 2024, as each Item Policy was rolled out comprehensively, reserves and equipment materials were affected. Each week, the department head over each circulation desk got a concise human-readable summary of what the intended impacts were from a change and what problems to look out for. Each department head also got a spreadsheet report of all items, if any, with the newly rolled out Item Policy assigned and was able to review it and ask any questions or address any problems.

After the 13 Item Policies were comprehensively rolled out in Alma, each checkout desk got a report of all items with Item Policies not to be retained long term, and was able to use the written spec to select a new Item Policy for each. Systems met with the head of each checkout desk on screensharing to look at the report and was able to add additional columns to assist in identifying items and sorting similar items together.

Following comprehensive roll out of settings and metadata cleanup, all circulating FUs behaved similarly. Locations were consolidated into a smaller number of FUs, and the FUs which had been emptied of Locations were deleted. The Alma install went from 17 FUs to six FUs. Lastly, the older circulation logic rules predating refactoring were deleted from remaining FUs.

Figure 11. Example email announcement of an upcoming settings change announced to an internal LISTSERV. When the change was later rolled out to production, a confirmation went out to the same LISTSERV.

Figure 12. A circulating FU at the end of the refactoring process. Item Policies defined in the spec were comprehensively set up in all circulating FUs. As metadata clean up completed on legacy Item Policies which would be discontinued, FUs were consolidated.

Streamlining Terms of Use

At the start of Fall 2024, highly varied Terms of Use were also addressed. Going into 2024, numerous Terms of Use had been built out in the Alma software, and were not referenced by any circulation logic rule at all. This included test settings, and deprecated settings, such as circulation behaviors which had been in use during COVID closures. Of the Terms of Use which were referenced, names indicated multiple Terms of Use accomplished similar intended behavior. For example, four separate Terms of Use defined checkout for four weeks with two renewals.

Within Alma, a Terms of Use can be deleted only if it is not referenced by any circulation logic rule. Before beginning refactoring, the University Libraries deleted all Terms of Use which could be deleted (i.e. all Terms of Use which were not referenced by any circulation logic rule). This reduced the total number of library and institutional level Terms of Use from 143 to 61. Unreferenced and deleted Terms of Use were not documented. Regarding the 61 remaining Terms of Use, the detailed settings for each was copy pasted into the data dictionary. As Terms of Use were later eliminated, each was marked “RETIRED” in the data dictionary. As Terms of Use detailed settings were edited, the edit was noted in the data dictionary with a redline of the change, and a note as to what date the change was made on Alma test and Alma production.

During the first four weeks of the Fall 2024 semester, Systems consolidated the existing Terms of Use. Any library level Terms of Use were eliminated. To do this, Systems used diff to compare the detailed Terms of Use behavior settings within Alma for the Terms of Use at the library level against Terms of Use at the institutional level which had names indicating a similar behavior. Systems identified the institutional Terms of Use with the most similar (or identical) behavior. Systems then scheduled a meeting with the department head over the checkout desk at each building. The meeting agenda included a summary of changes to Terms of Use which affected Locations served by that desk, and notes about any apparent differences between the Terms of Use to be deprecated and the new target Terms of Use. During the meeting, Systems changed the circulation logic rules for the building that that person’s checkout desk was located in away from referencing library level Terms of Use and to reference the most similar institutional level Terms of Use for each. By meeting on screensharing and clicking through and explaining the change during the meeting, heads of checkout desks could know that a change had been made, and could look out for subtle changes to behavior. Meetings included a maximum of three functional changes (i.e. consolidating all the week-long Terms of Use was one functional change, consolidating all the 4 day terms of use was another functional change), with the idea that that way the department head had a limited number of areas to look for problems in over the following week. Eliminating library level Terms of Use and instead referencing only settings at the institutional level further reduced the number of Terms of Use to 36 early in refactoring. Additional consolidation of Terms of Use with names indicating a similar intended behavior reduced the number of Terms of Use at the library and institutional level to 28 Terms of Use.

Impacts of Refactoring

Rolling out the streamlined settings and doing metadata cleanup had minimal impacts on day-to-day operations. By rolling out changes a little at a time, problems were minor and could be quickly resolved when reported. The effort was largely time spent in analysis of settings by Systems, and metadata cleanup by Cataloging. The process was not disruptive to checkout desks, not labor intensive, and involved keeping an eye out for unusual circulation behavior and reporting problems to Systems and Cataloging, which is something checkout desk already do on a day-to-day basis. Minimal disruption is by design. The essence of refactoring is small incremental changes, in order to avoid dramatic disruption (Fowler and Beck, 2018[30]). Also, key to not disrupting operations was the idea of streamlining existing behavior. During the refactoring process, settings and metadata were extensively edited, with Cataloging changing Item Policies for around 20% of the physical items in the University Libraries. The actual circulation behavior rarely changed for circulating items. Instead, during refactoring, a previous configuration in which dramatically different logic rules and metadata came to a similar outcome at different locations was replaced with the current configuration in which standardized logic rules and metadata come to an identical outcome at all locations.

While it may seem like a lot of analysis and effort to refactor the software, the time was quickly gained with more efficient overall workflows. Before refactoring, simple changes in checkout times for specific kinds of items took an inordinately large amount of analysis. Not having an explanation of how the software settings worked was a constant frustration for employees in varied roles. The benefits of refactoring are that problems with checkout behavior of any individual item can now be promptly solved by referencing a concise explanation of settings (Appendix A). Cataloging, checkout desks, and Systems can reference the shared documentation to quickly route and fix the problem, and to understand what options are already available for circulation behavior when cataloging a new item or launching a new collection. Time spent refactoring is recaptured with the day-to-day efficiencies of software that works smoothly.

Objective proof of improvements due to refactoring may be apparent in the rate of overrides on checkouts. In Fall 2023, approximately 16% of checkouts at Henderson Library, the busiest checkout desk serving the building with the largest physical collections, were accomplished by overriding a block on checkout, with numerous blocks being “Item is not loanable” indicating that combination of metadata settings was not configured for checkout within Alma. In December 2024, that number fell to just over 2% of checkouts accomplished with an override. Midway through the Fall 2024 semester and midway through the refactoring process, permission for student workers to override blocks on checkout was comprehensively removed without ill effects.

Conclusion

Refactoring is the process of restructuring existing code, in order to make the code easier to maintain, and without changing the behavior of the software. While software might over time fall away from a cohesive design, as new features are implemented one-at-a-time without explicit awareness of overall design, refactoring is an opportunity to bring a complex piece of software back into compliance with a comprehensive design. The University Libraries comprehensively refactored circulation behavior in the Alma ILS during 2024. Refactoring involved establishing basic infrastructure in the form of workflows for versioning software settings in Alma, writing a spec for software behavior, and then making incremental changes to streamline software settings. By developing and vetting a written spec with involvement from all stakeholders, and then making incremental changes in support of the design, overall software function improved. Improvement is shown tangibly by ability to quickly troubleshoot and resolve problems, which previously could only be resolved with long turnaround time and high effort, and by a dramatically reduced rate of overrides when checking items out to patrons.

Acknowledgements

The following people performed essential substantive work related to refactoring the University Libraries’ Alma instance: Rebecca Hunnicutt, Collection Management Librarian and Assistant Professor, Georgia Southern University Libraries; Justin Barnett, Network Services Coordinator, Georgia Southern University Libraries; Greg Vaughan, Metadata Quality Manager, Georgia Southern University Libraries.

Footnotes

[1]Within Alma, the Alma interface label two settings “Material Type”. One Material Type setting refers to Alma’s labeling of a controlled vocabulary defined within the bibliographic level leader 06 and 07 and 008 fields, and is not configurable. The other Material Type setting refers to a configurable item level metadata setting within Alma, and is not part of the MARC standard. Within this article, all references to “Material Type” within Alma refer only to the item level metadata setting.

References

[22]Bell S. Moving to mobile: Space as a service in the academic library. EDUCAUSE Rev. 2022 Apr 15. https://er.educause.edu/articles/2022/4/moving-to-mobile-space-as-a-service-in-the-academic-library

Brooks F. No silver bullet: Essence and accidents of software engineering. IEEE Comput. 1987;20(4):10-19. https://dl.acm.org/doi/pdf/10.1145/130844.130856

[11]Chan LM, Salaba A. 2023. Cataloging and classification : an introduction. 5th ed. Lanham (MD): Rowman & Littlefield 773 p. https://doi.org/10.1080/01639374.2024.2406770

[3]Coleman D. Growth promised as Armstrong, Georgia Southern merger made official. Savannah Morning News. 2017 Jan 20. https://www.savannahnow.com/story/news/2017/01/10/growth-promised-armstrong-georgia-southern-merger-made-official/13899055007/

[23]ExLibris. Voyager to Alma migration guide. [accessed 2024 Dec 30]. https://knowledge.exlibrisgroup.com/Alma/Implementation_and_Migration/Migration_Guides_and_Tutorials/Voyager_to_Alma_Migration_Guide

ExLibris. Configuring physical fulfillment [Internet]. [accessed 2025 Jan 2]. https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/030Fulfillment/080Configuring_Fulfillment/020Fulfillment_Infrastructure/Configuring_Physical_Fulfillment

[17][18]Florida Academic Library Services Cooperative (FALSC). 18ITN-06AJ Invitation to Negotiate Next Generation Integrated Library System (ILS). 2018 Dec 22. On file with the author.

[9]Florida Virtual Campus (FLVC). Florida Virtual Campus annual report 2013-2014. Florida Virtual Campus; 2014.

[27][28][29][30]Fowler M, Beck K. Refactoring: Improving the design of existing code. Addison-Wesley Professional 2nd edition; 2018.

[1]GaLiLeO Interconnected Libraries (GIL). ExLibris press release: University System of Georgia Selects Ex Libris Alma as the system’s next-generation library management solution [Internet]. Athens (GA): University System of Georgia; 2015 Jul 30. https://gil.usg.edu/alma_implementation/announcements/exlibris-press-release

[2]GaLiLeO Interconnected Libraries (GIL). Institutions live with Alma and Primo (OPAC) [Internet]. Athens (GA): University System of Georgia; 2017 Jun 27. https://gil.usg.edu/alma_implementation/announcements/institutions-live-with-alma-and-primo-opac

GALILEO Interconnected Libraries (GIL). GIL Express: General information [Internet]. Athens (GA): University System of Georgia; [accessed 2025 Jan 1]. https://gil.usg.edu/gil_express/information/general-information

[5]Ganz M, Slavin L. 2024. System migrations: Best practices and lessons learned. The Southeast. Libr., 72(3), article 4: 5-10. https://digitalcommons.kennesaw.edu/cgi/viewcontent.cgi?article=2098&context=seln

[19]Goek S. The state of U.S. academic libraries: Findings from the ACRL 2023 Annual Survey. Chicago (IL): Association of College and Research Libraries; 2024. https://www.ala.org/sites/default/files/2024-10/2023%20State%20of%20Academic%20Libraries%20Report.pdf

[20]Gonzales AL, Calarco JM, Lynch T. Technology problems and student achievement gaps: A validation extension of the technology maintenance construct. Communication Res. 2020;47(5):750-770. https://doi.org/10.1177/0093650218796366

[8][24]Heidari-Robinson S, Heywood S. Getting reorgs right. Harv. Bus. Rev. 2016 Nov.

[4][12]Lee J, Frost G. Manipulating data and moving forward: Transitioning to a shared cataloging environment. Collab. Libr. 2017;9(3 article 3):215-217. https://digitalcommons.du.edu/cgi/viewcontent.cgi?article=1351&context=collaborativelibrarianship

[14]The Library of Congress. 876-878 – item information-general information [Internet]. Washington (DC): The Library of Congress; 2008 Mar 11. https://www.loc.gov/marc/holdings/hd876878.html

[13]The Library of Congress. MARC standards [Internet]. Washington (DC): The Library of Congress; 2023 Jun 15. https://www.loc.gov/marc/

[10]The Library of Congress. MARC 21 format for bibliographic data: 1999 edition update no. 1 (October 2000) through update No. 39 (December 2024) [Internet]. Washington (DC): The Library of Congress; [accessed 2024 Dec 31]. https://www.loc.gov/marc/bibliographic/

[15]McCallum SH. MARC: Keystone for library automation. IEEE Annals of the Hist. of Comput. 2002;24(2): 34-49. https://doi.org/10.1109/MAHC.2002.1010068

[26]McDaniel G. IBM dictionary of computing. Tenth ed. McGraw-Hill, Inc.; 1994.

[16]Moehrle D. MARC of the future. PNLA Q. 2012;76(4):81-87.

[6]Nicholson J, Tokoro S. Cloud hopping: One library’s experience migrating from one LSP to another. Tech. Serv. Q. 2021;38(4):377–94. https://doi.org/10.1080/07317131.2021.1973796

[25]Red Hat. What is YAML? [Internet]. Red Hat, Inc.; 2023 May 3. https://www.redhat.com/en/topics/automation/what-is-yaml

[7]Rinna G, Swierenga M. Migration as a catalyst for organizational change in technical services. Tech. Serv. Q. 2020;37(4):355–75. https://doi.org/10.1080/07317131.2020.1810439

[21]Wilmoth WS. Circulating laptops in a two-year academic library: A formative assessment. Ga. Libr. Q. 2015;52(4):1-11. https://digitalcommons.kennesaw.edu/cgi/viewcontent.cgi?article=1846&context=glq

About the author

Wilhelmina Randtke has a background in law and technology. Her past roles include legal research, technology oversight, and product manager for cloud based publishing software. She is currently Head of Libraries Technologies and Systems at the Georgia Southern University Libraries overseeing in-building technology and online presences. Georgia Southern University Libraries is the largest student printing lab on campus, providing approximately 1,500,000 prints to students each year. The libraries provide in-building desktop computers with specialized software for academic projects, a fleet of approximately 190 checkout laptops for students, and 3D printing and scanning services.

Appendix A: Software spec posted to all employees on the University Libraries intranet before refactoring software settings.

Item Policies and behavior for each (goals; not yet implemented as of summer 2024)

Noncirculating Special Collections Locations (Location Overrides Item Policy)

Locations included:

• Henderson Library
  • Special Collections Oversize_ZSH (code=SPECCOLOV)
  • Special Collections Reading Room_ZSH (code=SPECCOLL)
• Lane Library
  • Special Collections Minis Room_LL (code=MINIS)

Item Policy: All items in all Special Collections locations should have an Item Policy of “Noncirculating Special Collections”.

All items in these locations should be not checkoutable, no matter what the Item Policy is. Additionally, for these locations, the location should also prevent requesting to where the ARC robots never grab any item automatically.

Noncirculating locations (Location overrides Item Policy)

Locations with no canonical Item Policy: Because these are temporary / processing locations, the entire location is noncirculating regardless of Item Policy:

• Henderson Library
  • Available Soon_ZSH (code = AVAILSOON )
  • Bindery (code = Bindery )
  • Collection Services_ ZSH (code = CRSPROCESS )
  • CSDPAY_ZSH (code = CRSPAY )
  • Docs US Map Cases_ZSH (code = DOCSMAPS )
  • Docs US Reference_ZSH (code = DOCSREF )
  • Foy Media (code = FOYMEDIA )
  • ARC Media_LL (code = ARCMEDIALL )

Locations with a specific Item Policy which should be used for that location:

• Henderson Library:
  • Herbarium (code = HERBARIUM )
    • Item Policy: All items in “Herbarium” should have an Item Policy of “Non Circulating”.
• • Microform Area_ZSH (code = MICROFORM1 )
    • Item Policy: All items in “Microform Area_ZSH” should have an Item Policy of “Non Circulating”.
• • Microform Periodicals/Newspapers_ZSH (code = MICROFILM2 )
    • Item Policy: All items in “Microform Periodicals/Newspapers_ZSH” should have an Item Policy of “Non Circulating”.
• • PTRC-Henderson (code = ZSH_PTRC )
    • Item Policy: All items in “PTRC-Henderson” should have an Item Policy of “Non Circulating”.
• • Reference 1st Floor_ZSH (code = REFERENCE )
    • Item Policy: All items in “Reference 1st Floor” should have an Item Policy of “Non Circulating”.
• • Reference Atlas_ZSH (code = REFATLAS )
    • Item Policy: All items in “Reference Atlas_ZSH” should have an Item Policy of “Non Circulating”.
• • Withdrawn Learning Commons (code = WDLCOMM )
    • Item Policy: All items in “Withdrawn Learning Commons” should have an Item Policy of “Withdrawn”.
• • Withdrawn _ZSH (code = WITHDRAWN )
    • Item Policy: All items in “Withdrawn _ZSH” should have an Item Policy of “Withdrawn”.
• • Withdrawn: ZSH Surplus Equipment (code = ZSHSurplus )
    • Item Policy: All items in “Withdrawn: ZSH Surplus Equipment” should have an Item Policy of “Withdrawn”.
• Lane Library:
  • Periodicals_LL (code = PERIODICAL)
    • Item Policy: All items in “Periodicals_LL” should have an Item Policy of “Non Circulating”.
• • Reference_LL (code = REF)
    • Item Policy: All items in “Reference_LL” should have an Item Policy of “Non Circulating”.
• • Withdrawn _LL (code = WD)
    • Item Policy: All items in “Withdrawn _LL” should have an Item Policy of “Withdrawn”.

Circulating Locations: Stacks locations with a mix of circulating and non circulating items (Item Policy determines behavior)

Circulating stacks locations (will have a mix of circulating and non circulating items):

Item Policy: All Item Policies in the table are allowed in these locations, except for not “Withdrawn”.

Locations included:

• Henderson
  • ARC Books_LL (code = ARCBookLL)
  • ARC Books_ZSH (code = ARCBook)
  • ARC Docs Ga_ZSH (code = ARCGovGA)
  • ARC Docs US_ZSH (code = ARCGovUS)
  • Authors’ Lounge ZSH (code = AUT_LO_ZSH)
  • Brain Booth_ZSH (code = BB_ZSH)
  • Docs Ga CD/DVD Cases_ZSH (code = DOCSGACD)
  • Docs Ga Oversize_ZSH (code = DOCSGAOVR)
  • Docs Ga Stacks_ZSH (code = DOCSGA)
  • Docs US CD/DVD Cases_ZSH (code = DOCSCD)
  • Docs US Stacks_ZSH (code = DOCSSTACKS)
  • Foy Oversize (code = FOYOVER)
  • Foy Stacks (code = FOYSTACKS)
  • Graphic Novels_ZSH (code = GraphicZSH)
  • Lorimer Reading Room_ZSH (code = LORIMER)
  • Popular Reading_ZSH (code = popularZSH)
  • Stacks 3rd Floor_ZSH (code = STACKS3)
  • Stacks 4th Floor_ZSH (code = STACKS4)
  • Stacks Oversize 3rd Floor_ZSH (code = STACKSOVR3)
  • Stacks Oversize 4th Floor_ZSH (code = STACKSOVR4)
• Lane:
  • Authors’ Lounge – Lane (code = AUT_LO_LL)
  • Brain Booth_LL (code = BB_LL)
  • Compact Stacks_LL (code = COMPACT)
  • Compact Stacks Oversize_LL (code = COMPOV)
  • Juvenile_LL (code = JUV)
  • LL Displays (code = DISPLAY)
  • Microform Area_LL (code = MICROF)
  • Stacks 2nd Floor_LL (code = MAINSTACKS)
  • Stacks Oversize_LL (code = FOLIO)
  • Graphic Novels LL (code = GraphicLL)
  • Popular Reading_LL (code = POPREADING)

Circulating Locations: Reserves and Behind desks locations (Item Policy determines behavior)

Reserves and behind desks locations.

Item Policies: All Item Policies in the table will work in these locations.

Never apply the following Item Policies to items behind a desk. If it can’t be checked out, and it’s behind a desk, then no one can use it. Everything behind a desk should circulate to someone:

• “non circulating”
• “Withdrawn”
• “Noncirculating ARC materials (2 hour in building)”
• “Noncirculating Special Collections (noncirculating)”

Be very cautious applying the “Standard (4 weeks)” Item Policy to items behind a desk. With a long checkout period, an item can be checked out for a long while, and be gone for the semester.

Locations included:

• Henderson:
  • Foy Reserves (code = FoyReserve)
  • ZSH Course Reserves (code = CourseRes)
  • ZSH Reserves (code = ZSH_Reserv)
  • ZSH Equipment (code = Equipment)
  • ZSH Repairs (code = ZSHRepairs)
• Lane:
  • Media Reserves_LL (code = AVRESERVE)
  • Reserve_LL (code = RESERVE)
  • Learning Commons:
  • Learning Commons Desk (code = LCOMM)