This was recorded for CNI’s 2022 Project Briefing Series.
The 21st century academic library runs on an increasingly interconnected network of systems, from the traditional ILS to emerging technologies. While they support core library functions, these products are often implemented without a plan for their maintenance in the years or decades until their sunsetting or the next migration. Drawing from the emerging field of maintenance studies, this presentation will share results from qualitative interviews of 16 ILS maintainers and propose steps for building a workplace where core maintenance tasks are recognized and supported.
My presentation today builds from my own experience here and as a repository librarian, from research I’ve conducted, and from the emerging field of maintenance studies. I have also written about these findings for an article to be published in College & Research Libraries in January 2023, currently available as a pre-print in Penn State’s institutional repository, ScholarSphere.
To begin, what makes maintenance worth researching? If you’re getting reports from library’s digital teams, you know they’re already doing a lot of maintenance – upgrading servers, patching Drupal, necessary work but not the stuff that’s likely to get us excited. I think there’s a lot of reasons and I’m going to list a few key ones here.
Maintenance is understudied in comparison to the role it plays in our day-to-day work. When I asked ILS/LSP maintainers to estimate how much of their work week is spent on maintenance-related tasks, their numbers ranged from 40-60% depending on how strictly we were defining maintenance. But our research, surveys, and case studies focus almost exclusively on migration or implementation of new systems or on development projects. While we assume we know what goes into maintenance, my research suggests that its low visibility negatively impacts both the institutions and the individuals who perform it.
Moreover, maintenance is key to getting a return on the significant financial investment we’re putting into these systems. In a time of budget recisions, we’re still paying hundreds of thousands of dollars for the systems on which our libraries rely. We’re paying far more for collections. If we don’t also invest the time in making sure the systems are properly implemented, integrated with other services, and then maintained, it’ll put up barriers between our patrons and the use of those collections, as well as slow down our colleagues in the efficient completion of their own work.
As the pandemic, fires, and floods we’ve been experiencing through the last decade are teaching us, libraries need to adapt quickly to support their community bases through a crisis. If our systems aren’t well-maintained, we’ll be on poor footing to respond.
Understanding, prioritizing, and budgeting appropriate time and money for maintenance work is important to the morale of both the workers doing the maintenance and the workers using the end products.
We’re good at rewarding innovation and celebrating new implementations, but we’re much less likely to recognize the work that goes into keeping that new product running for another 5 to 20 years. This means that, structurally, some colleagues will be recognized over and over again and others will feel that their work is ignored, even if that work is equally critical to the institution.
Lack of maintenance also affects the morale of all workers using a system. It interrupts their flow, forces them to find workarounds, and leads to negative interactions with patrons when a system is not behaving as expected.
Before sharing my research, I want to spend a little time on how I define maintenance in this context.
“Acts that sustain or repair… the interfaces we design to function between and among information systems”
Given the proliferation of library systems and integrations, I think the Information Maintainers’ expansion of Russell and Vinsel’s 2016 definition of maintenance as acts that sustain and repair people and things to include “the interfaces we design to function between and among information systems” is particularly appropriate here.
I’m going to make it a little more concrete by naming some of these acts, including:
The latter type of work spans maintenance and innovation, but when it consists of bringing existing systems into alignment with expectations and work already being performed, it aligns more closely with other areas of maintenance included here.
And while defining maintenance, I think it’s important to clarify: maintenance is not inherently good. Sometimes people maintain oppressive systems, harmful technologies, or just unused projects. Or we commit to maintaining more than we have capacity for, as Brent Davidson and Jason Ronallo discussed in their CNI 2018 presentation on Sunsetting.
But it’s only once we examine maintenance as a meaningful and valuable part of library work that we can identify the things we shouldn’t be maintaining.
Most of the research that has been done related to library systems maintenance has been survey-based and focused developing a concrete list of tasks, generally these are intended to improve education and hiring practices or on understanding a single element of the work. I oriented my research toward identifying shared themes in the experience of performing systems maintenance over years or decades and the implications for practice.
I lay out my methods in the paper, which I’ll share at the end of my presentation. One area of recruitment which I will mention here, however, was ensuring that at least 2 interviewees supported each of: Aleph, Alma, Sierra, Symphony, and Voyager. Several participants who had migrated to Alma in the last few years could speak to maintenance of multiple systems.
I iteratively coded the interview transcripts in NVivo, identifying five interrelated themes:
While I spell these out in greater depth in my article, for today’s talk I’m going to focus on:
and fold in elements of the other two themes.
Systems maintenance tends to consist of an unpredictable mix of the following elements:
While certain kinds of maintenance, such as upgrading a system or implementing a quarterly release can be planned ahead of time, that does not inherently make them predictable. For example, Alma maintainers knew a quarterly release was coming but they don’t know what was in it, whether it would affect library processes and integrations, whether it required stakeholders to perform testing choose how it was implemented, etc., until they had time to read the release notes.
As with planning, the amount of time spent performing planned maintenance varies widely based on the kind of work needed. And as I recently experienced with one of our integrations, if something isn’t documented in the release notes, your expectations may turn out to be completely off-base.
Moreover, each integration, modification, or enhancement becomes another area that requires monitoring, maintenance, and may break without notice. These build up over the lifetime of a system as the library adds new services, supports new workflows, etc.
And because a maintainer’s primary job is to keep the system working, malfunctions take priority over the kind of long-term enhancements which provide the most visible evidence of one’s productivity. These may range from something as simple as restarting a service–which is just enough to interrupt focused work–to dropping everything and spending a week ensuring the high-risk, headline-making log4j vulnerability has been fixed on all the library’s systems.
If this unpredictability is not understood and incorporated into expectations for the position alongside more visible work, providing responsive support to patrons and colleagues or just keeping the system from falling apart will lower a person’s perceived productivity.
When successful, systems maintenance is rarely visible to those outside the library’s technical departments. This invisibility can lead to an expectation that those performing it will be available to take on new projects.
“I wish [others knew] that you have to work hard to be unnoticed”
The participant quoted here noted that they team they’re on spends about 60% of their time maintaining and supporting their ILS and its many integrations. Another said that it’s hard to convey the amount of work it takes to “keep the lights on,” which is often made up of a series of tasks that seem insignificant in themselves.
If this work is not accounted for when new initiatives arise and require their support, maintainers find themselves choosing between delaying the completion of the new project or leaving users in the lurch.
Participants also noted that non-technical elements of their work may not be visible in the way that technical work can be. For example, estimates on time spent on communications work ranged from 10%-25% of a workday/workweek including everything from troubleshooting an issue through emails and service tickets to big meetings planning maintenance or fostering trust necessary to perform bigger maintenance tasks.
One participant explained that they frequently take walks as a way of stepping away from the screen and thinking through a problem they’re trying to solve, but worry that this might be perceived as not doing the work in the same way that sitting in front of a screen might.
The invisibility of maintenance work also leads to incidents which harm morale. Two respondents mentioned that their institutions recently honored and praised highly-visible front-end developers for completing projects, even when they had been an equal or primary contributor. As one said:
…nobody mentioned me, nobody mentioned the months that I spent working on this, and my direct supervisor still does not recognize that that work had to be done. Nobody ever knows that my work comes first and then the guy who worked on the website gets to do the cool thing that everyone can see.
This leads to a thread which wove through the interviews: the demoralizing effect of invisibility when things go well, of hypervisibility when things go badly, and not having capacity to do the job to one’s own standards. Half of participants reported that they regularly worked more than 40 hours a week and all participants said that they are unable to do some maintenance that would make the system function better for others because it’s not actually broken and they don’t have time.
While capacity was partly determined by one’s workload, it was also impacted by work being done outside the library–sometimes University IT, but more often vendors. When the system is not working properly but not so broken that the vendor responds immediately, it may be three months or more for a fix to be released.
But, as Scarlet Galvan said in her 2018 VALA keynote, “And yet, when there’s an outage or we can’t provide a resource, it’s the library’s problem—not the vendor’s.”
As one participant shared:
[delays in vendor response] really impacts our unit’s reputation within the library but also our library’s reputation within the university.
While some things, like development timelines or another log4j crisis, are mostly outside our control, we can develop a strategic approach to maintenance which provides better service to our communities and mitigates some of the stressors our colleagues experience.
First, make the invisible visible: document what you’re actually maintaining. Not just the systems but the interoperability between them and what they’ve required in the past – does your ILLiad connect to your LSP with custom code? Does your library account management tool use a WebService that sometimes times out for no known reason? Which systems or integrations are particular pain points that fail more often or take more time to handle when they go down? Get the details as well as the big picture.
Next, find out what you’re not maintaining – or, more likely, not maintaining as well as you could be. What would your systems teams do if they had more time or another position? Collect it all, from the barely-contained disasters to the “we could really serve X community better if only we had time to fix/implement/update Y.”
Then, identify what you’re going to maintain. Is it a core service? Are you paying NDAd sums for the software but it’s only running half as well as it could be because your workers haven’t had capacity to fully implement and maintain it? You’re already doing less, but you’re not being strategic about it.
Include maintenance work in your strategic planning. Be clear which innovative projects are purely experimental and which you’re committed to maintain. Make sure you have a plan for their maintenance as well as their development. Commit to the systems and services that you can maintain well, not everything you can do if you burn out all your workers.
In his 2021 article in Library Leadership and Management, “A Good Jobs Strategy for Libraries,” Trevor Owens called for library leaders to reconsider the “do more with less” approaches that have been burning out workers and take the bold step of consolidating services while not cutting jobs. This is the same recommendation that Davidson and Ronallo made in their 2018 CNI talk on sunsetting.
Both also point to work on the benefits to an institution when workers have “slack” in their schedules. When every minute is engaged and the backlog is full of smoldering fires, workers have much less capacity to think about how to do the work better or develop innovations – or even when they can think of it, they don’t have the time to follow through.
“It seemed to surprise people that went that there was so much more being done. I think most people were under the impression that [a single] systems person can just handle all the behind the scenes stuff and keep things humming along smoothly.”
Of course, you don’t necessarily have to do less, you just have to commit to funding maintenance work with more slack than your workers probably have at present. That could mean adding positions. Two participants described the process by which their institutions realized they could get a lot more value out of their Alma implementations if they hired another person to support it. By documenting what was possible but couldn’t be done given their current staffing levels, their managers developed job descriptions which they successfully justified to the library administration.
This not only benefited (and pleasantly surprised) the rest of the library, it benefited the workers doing the maintenance. Not only were they able to focus more on the tasks while knowing other work was getting done, tangible recognition that their work has value to the library lifts the morale of those doing it.
And on that note, something that everyone in libraries can do is make sure that maintenance work is rewarded alongside innovative and creative work. When celebrating an achievement, give appropriate credit to those who did the behind-the-scenes work or maintain the underlying system as well as those who did the most visible parts. Such an acknowledgement is one step toward balancing out the tendency for maintainers to be most visible when something breaks.
If you know that you’re not entirely familiar with the work of some of your coworkers, this may mean asking the department if you’re missing anyone before putting in a kudos or nominating a group for an award. And don’t just celebrate the innovative achievements that benefit the public. Did someone just make it a little easier to for another team to do their jobs or fix a broken system that was making your life harder? Thank them and acknowledge it in whatever way is appropriate in your library.
“It’s so easy, I think, for an administrator to be focused on what makes us look good and less about [making] sure our users continue can continue to access the systems that we provide. “What ends up happening is: we’re constantly putting out fires because we don’t have a plan for maintenance. We don’t have adequate staff to keep everything going.”
When we neglect maintenance work, we risk degrading our core services, our reputations, and our institutional morale. What’s up to library leaders is to decide whether our libraries will offer more things and do all of them less well or pass on some exciting opportunities but come in strong behind what we offer.
Thank you.
My article: Tillman, Ruth. “Indispensable, Interdependent, and Invisible: A Qualitative Inquiry Into Library Systems Maintenance.” forthcoming in College & Research Libraries, January 2023. Green OA: https://bit.ly/TillmanSystems (Penn State IRB #: STUDY00015392)