Category Archives: Project Management

Find your team, and get to work(flows)

Posted on by

By Peggy Griesinger and Mikala Narlock

Digital collections are deceptive; when users turn to online platforms to access content, the amount of work required to provide uninterrupted access to digital materials is not always obvious or clear. One aspect of this work is taken care of by our software developers and product owners, who work to ensure that the interface and user experience are as simple and effective as possible to our end-users. While that aspect of the work is handled, other library staff and faculty must then take on the not insignificant job of digitizing, describing, and making accessible library, archive, and museum materials before they can be accessed online. While it is beyond the scope of this blog post to discuss the nuances and particulars of digital collections writ large, we will briefly describe how digital collections are produced at Hesburgh Libraries, why workflows are so crucial, and how we are focusing on sustainability to ensure the long-term success of this type of work.

Team meeting in a room

The Workflow Team hard at work.

About Digital Collection Management at Hesburgh Libraries

At Hesburgh Libraries, the process of creating digital collections is managed by a team of ‘Case Managers,’ individuals responsible for overseeing projects and ensuring that collections are processed efficiently and following standardized processes. Established in 2018, this low-tech approach to workflow management is based on project management principles to ensure the timely completion of requests. The case manager provides guidance and support for digital collections, and serves as a liaison between units. As Case Managers, we are tasked with working with subject selectors to identify collections, triage requests, and determine how best to digitize the content. Using modular workflow components, such as “Send to Conservation,” or “Route to Metadata Services,” we can build custom workflows to ensure all collections receive the appropriate care without stalling in a bottleneck area. Additionally, Case Managers serve as the primary contact for all project participants, and keep everyone apprised of progress and hindrances. Every digital collection, ranging in complexity and size from one diary to hundreds of boxes, is assigned a Case Manager to ensure there is always formal project oversight and that collections are not left behind in the event of personnel change. This team of case managers is called the Digital Collections Oversight Team (DCOT).

The oversight provided by DCOT is crucial to avoiding stumbling blocks in the complex process of creating digital surrogates for collection materials. Potential stumbling blocks include, but are not limited to: the digitization itself; additional processing requirements, such as in the case of archival collections; physical conservation needed to ensure materials are not damaged in the digitization process; additional descriptive information requiring the intervention of experienced catalogers; copyright review; and other concerns unique to particular collections, such as a need to be able to batch-process catalog records or transport materials to a vendor. Every collection calls for a slightly different workflow, but, at the same time, each project provides more experience and practice for our team to more comprehensively understand digital collections workflows at the Libraries. Given efforts at Hesburgh Libraries to identify a Libraries-wide digital collections platform, we are aware that the workflows we develop and document will be crucial for effectively creating and delivering digital content in ongoing and future efforts, including the MARBLE site.

A soldier climbing a mountain of books, title reads Knowledge Wins

A recently added World War I-era poster proclaiming the importance of libraries .

Workflows for MARBLE

In keeping with the collaborative spirit of the MARBLE project, we have focused on simplifying our workflows across departments and aligning processes between the library and the museum. In reducing the number of discrepancies between the workflows, we can automate processes and simplify the burden of labor on Case Managers and other stakeholders. We started this effort by sketching out anticipated workflows, taking into account variables such as: the existence of descriptive metadata, whether an item was a library or archival material type, and the custodial department responsible for the item. During this process, it became apparent that, despite anticipated discrepancies in workflows, many of our procedures were already aligned, even if we sometimes used different terms to explain related concepts. Additionally, the work of our developers has allowed us to align our existing workflows in a way that will enable each unit to continue using its own best practices while still automating the process of content ingest into MARBLE in a consistent and standardized manner. Building this ability on top of our existing systems will allow us to continue using workflows that are effective for each unit while at the same time easing the process of conciliating diverse collections so they can be accessed on a shared platform like MARBLE.

 

Ensuring Sustainability

Workflows for creating and managing digital content are critical to the success of any digital library. We expect demand for digital facsimiles to increase as traffic to the MARBLE site continues to grow, especially during this period of heavy reliance on online classes and virtual instruction. Our team is looking to grow sustainably, and ensure that many people, particularly those embedded in custodial departments, are able to upload content to the MARBLE site without confusion, significant efforts, and bottlenecks. Our overall focus is on making use of existing expertise, staffing, and workflows while also ensuring those disparate pieces work well together and lead to solutions, like the MARBLE project, that make the cultural heritage of Notre Dame institutions more widely accessible.

 

 

Documenting Decisions to Build Buy-In

Posted on by

by Jeremy Friesen 

Introduction

In any long-running project at Hesburgh Libraries, our developer teams make countless decisions every day. Some decisions are big and some are small. — some affect a few people while others have an impact on the entire organization.

Inevitably, these decisions evolve over time. 

Sometimes we have to adjust or even reverse a decision after gathering more information or gaining experience with a tool or software. We don’t sweat the ebb and flow — we welcome it. Embracing decision-making as an evolutionary process is one of our guiding principles for a healthy team culture.

We also realize that decisions are only as good as the documentation and communication processes that underpin them.

Photograph of a horse from various angles

Documenting our decisions from every angle helps us understand where we’re going and why. Image: Eadweard Muybridge, “Eagle” Walking, Free, plate 576 from Animal Locomotion, 1845-1904, albumen silver print. The Janos Scholz collection of 19th century photography, Snite Museum of Art, University of Notre Dame, 1981.031.543.

To this end, we use consistent documentation and transparent communication to serve as a two-way roadmap for new challenges, team discussions, and retrospectives in the midst of a rapidly changing landscape. 

These decision documents also help to facilitate conversations with stakeholders and build enduring relationships with project partners.

The cases below illustrate how decision documents and transparent communications during the MARBLE project have contributed to team success and project impact.

A tale of two documented decisions

One of the goals of the MARBLE software development project funded by the Andrew W. Mellon Foundation is to create a unified discovery for digitized cultural heritage collections held by the Snite Museum of Art and Hesburgh Libraries at the University of Notre Dame. 

Our immediate aim is to make these objects discoverable in the context of a collaborative digital collections platform. We also surmised that we may want to someday make the digitized objects discoverable through our general library catalog. 

Given these aspirations, we decided to leverage the library-wide discovery system as our search and discovery interface. library-wide discovery system is a vendor-supplied search index software used by many libraries around the world as their primary catalog. 

On the surface, this decision ran contrary to another goal of our project: to develop and release open-source software.

To reconcile these apparent contradictions and keep our road map intact, I wrote a decision document supporting the use of our library-wide discovery system and how we would proceed with delivering open-source software. We clarified that we would use an API to interact with our search index. (An API, or Application Programming Interface, is a protocol or specification that allows information to transfer from one system to another. Using an API is a simple and common practice in developing new software.) 

In this case, we viewed the decision to interact with an API as a way to support other institutions or potential adopters that don’t use our discovery system. In other words, our solution would be built in such a way that another institution could connect with their search index of choice.

We shared our draft decision with project leadership, stakeholders, and developer teams to solicit feedback. From the feedback, we amended the draft document to reflect any new considerations, questions, and challenges.

With a decision document firm in hand, we began working on implementing our solution. We gathered help from other library-wide discovery system adopters. (Thank you, Northwestern Libraries!). We dove deeper into our usage of library-wide discovery system, expanding our expertise and understanding of a technology we have long used.

Then we hit a wall. 

Our user interviews identified full-text search as a key desired feature. According to library-wide discovery system documentation, this functionality should have worked. But, it didn’t, and we entered into a “waiting on vendor response” holding pattern.

While waiting, one of our developers explored ElasticSearch as another option.. After only a  few afternoons of work and testing, ElasticSearch proved to be a viable alternative. Within a week, we referenced our documents. We reassessed our prior decision to leverage our library-wide discovery system and chose to pivot towards ElasticSearch. 

Drawing of a dancer

Pivoting on a decision takes balance and flexibility. Image: Edgar Degas, Study of a Ballet Dancer, ca. 1880-1885, brown conte crayon and pink chalk on paper. Gift of John D. Reilly ND’63, ’64 B.S., Snite Museum of Art, University of Notre Dame, 2004.053.004.

Again, I wrote up a decision document outlining the rationale, process, and lessons learned. For example:

  • We found that ElasticSearch allowed us to implement the full-text search feature.
  • ElasticSearch also performed faster searches
  • There existed open-source ReactJS components for facet rendering, something we were going to need to create in our previous approach.
  • Since ElasticSearch is open-source, our own developers can work out bugs instead of waiting on a vendor. 
  • Our decision to explore our existing library-wide discovery system also produced useful outcomes in that we have a deeper understanding of how to better leverage our library-wide discovery system in our current workflows.
  • The quick swap from one system to another confirmed for us that we have a robust architecture. 
  • Finally, we have postponed the goal of ensuring that all campus cultural heritage content is in our library search index, but our software design will make this work easier going forward.

Amazon Web Services: Are you being serverless?

Another problem we encountered during the development of the MARBLE project was choosing an International Image Interoperability Framework (IIIF) compliant image server. 

Early in the project, we chose to implement Cantaloupe from the list of known server options. With that decision documented and shared, we built blueprints to deploy our Cantaloupe instance into Amazon Web Services (AWS) as a Fargate container.

This worked to get us started.

However, as we added more and more images to Cantaloupe, we encountered problems such as spikes in response times, incidents of high error rates, numerous restarts. We soon discovered the root cause: Cantaloupe’s architecture conflicts with AWS’s Fargate container implementation.

Our options were to move to a more expensive AWS service or look for something else and a possible contender emerged.

Our colleagues at Northwestern University, David Schober and Michael Klein, presented “Building node-iiif: A performant, standards-compliant IIIF service in < 500 lines of code” at Open Repositories 2019. After a quick conversation, they pointed us to their implementation, a serverless service.

Learning from our community is crucial to the development process.
Image: Flemish, The Lawyer’s Office, after Marinus van Reymerswaele, 1535-1590, oil on cradled panel. Gift of Dr. and Mrs. Dudley B. Kean, Snite Museum of Art, University of Notre Dame, 1954.005.

As has become our practice, we documented a plan to experiment with the serverless implementation. 

  • We kept Cantaloupe running for our pre-beta site, while we tested and expanded on Northwestern’s implementation.
  • On October 8th, we made the decision to move away from Cantaloupe. 
  • On November 7th, we switched from using Cantaloupe to using Northwestern’s IIIF-Serverless in our pre-beta instance. This was done without downtime or disruption to our site. 
  • Based on our findings we believe we’ll be able to reduce our image server costs by two orders of magnitude.

You can see our archived image-server repository and a snapshot of the blueprints to build this out in AWS. Here is the code commit that moved our blueprints from Cantaloupe to Serverless. You can also look at our documentation evaluating migrating from Cantaloupe to serverless.

Conclusion

The key takeaway is that it’s worth taking the time to document decisions and have consistent communications. 

It’s true that not every decision necessitates thorough documentation. However, the decisions that require widespread buy-in, impact a key tool or process, or re-orient project goals deserve an organization-wide commitment to this evolving decision-making process. 

For me, decision documents should identify the problem that needs to be solved and includes context, considerations, and constraints. Teams should build decision documents by seeking the input of those with a significant stake in this problem.

Because we have taken the time to document milestones and decisions, our project is modeling how to have a more robust memory of a particular problem and attempted solutions. We are able to be visionary and more agile as we create solutions to meet stakeholder needs.

Simply said, decision documents make all the difference.

And, as a bonus, it was much easier to write this blog post. So, go forth and document! 

 

Teamwork Makes the Dream Work

Posted on by

By Abigail Shelton 

At universities, there is often the desire for project partnerships, but differing organizational priorities sometimes inhibit true, long-term collaboration. The question is, how can two independent campus departments work effectively together toward sustainable outcomes?

At Notre Dame, the leadership for Hesburgh Libraries and the Snite Museum of Art started by identifying a project with shared goals that aligned with institutional priorities. 

Securing funding was the next step. The partners jointly submitted a grant proposal for a three-year project, the success of which depended on multiple stakeholders working together to develop collaborative solutions over time. In December 2017, The Andrew W. Mellon Foundation funded Notre Dame’s project to create a unified discovery and access platform for library and museum collections. 

It was clear early on that the project’s complexities demanded that technical and subject matter experts from both organizations had appropriate representation and a framework to sustain what would become a new, shared campus service. Ultimately, strong project management, persistent outreach, ongoing communication, and cross-departmental teams became important ingredients to collaboration. 

Early Planning and Outreach

Project organizers set some basic guidelines for collaboration: each unit would receive one grant-funded position; team members would regularly work in each other’s spaces; the project team would meet every quarter for an update; and staff would tour and gain familiarity with each others’ collections.

These structures worked well for those directly involved in the project’s work, but there was still a question of how to ensure the diverse community of experts from the museum and library were also involved and invested over the long-term. 

The first strategy was targeted outreach by the Outreach Specialist who met one-on-one with library and museum curators, archivists, subject specialists, metadata librarians, and other stakeholders. Project staff also held quarterly meetings open to all library and museum personnel to hear project updates, ask questions, and learn about next steps. The outreach specialist and project manager also began working towards a website and blog to be a communication resource for staff as well as the wider world.

The Content Team Forms 

As 2019 approached, the core team realized that they would also need needed investment from collections experts to make decisions about digital content. They invited curators from the Snite Museum of Art, archivists from University Archives, curators from Rare Books and Special Collections, and librarians from Hesburgh Libraries to form the Content Team. Led by a curator from Rare Books and Special Collections, this group began to meet regularly to select representative content from across collections for inclusion in the platform. 

This team organized the first batch of content around a theme that could encompass materials from the archives, library, and museum. In choosing performance as the opening topic, curators drew from the library’s rich sports collections, Irish music broadsides, and religious materials. Museum specialists selected objects from the Meso-American collections, prints depicting historic theater performances, and a portrait of one of the greatest nineteenth-century French actors, among others. Archives staff selected Notre Dame student jazz festival programs, historic commencement programs, and speeches from the University’s beloved past president, Rev. Theodore Hesburgh.

PPT slide with digitzed books, photographs, and archival materials

Sample of selected content

The team was sure to choose diverse formats — from photographs and print materials to three-dimensional objects and paintings — in order to challenge the next two teams in the chain: Workflow Team and Metadata Team.

From Content to Workflow and Metadata

After forming the Content Team, the core project team created the Workflow Team to empower those who would ultimately implement the project workflows. Once the Content Team handed off the first test batch, the Workflow Team set out to take the raw material and make it accessible online.

The first challenge was to identify the source systems for the digital assets and associated information for the pilot collections. Hesburgh Libraries and the Snite Museum of Art have been digitizing their rare materials for conservation, research, and teaching purposes over the course of several decades. As a result, digital images are scattered across a range of storage locations including file folders, hard drives, and cloud-based storage systems. 

The associated metadata is also dispersed across several locations, such as an integrated library system (ILS), proprietary museum database, ArchivesSpace (finding aids for archival materials), standalone websites, spreadsheets, our institutional repository, printed catalogs, digital exhibits, museum object files, and most importantly, the minds of our subject specialists. 

Once the Workflow Team identified the source systems, they began talking to the gatekeepers about formats and access. The team is currently working towards moving digital assets and metadata from their current locations into a directory structure, through a IIIF pipeline, into the search index, and ultimately to the user interface. 

Image of group working at desks and white board with diagrams

Workflow Team meeting and diagrams

A Metadata Team was also started to engage experts from each organization to make collaborative decisions about how to manage metadata across the platform. They work in tandem with the Workflow and Content Teams to plan for metadata remediation and mapping. 

One of their greatest challenges is devising a solution that enables a robust search across archives, museum, and library collections when each project partner uses different data standards and formats. 

The team has been working on better understanding how each partner is cataloging their items and storing their metadata. In the next phase of the project, the team plans to make recommendations for how to reconcile subject term differences and develop basic metadata profiles. They will also document how to map museum and archival metadata into a unified search index so that users can search across the repositories’ holdings. 

Screenshot of website with painting on leftside and metadata on rightside

Metadata display for painting from Snite Museum of Art

The Foundation of Collaboration

At the onset, the core team understood that the software would only as successful as the collaboration and the long-term commitment of the people behind it. Opportunities for staff in the museum, library, and archives to better understand each others’ collections, professional best practices, and workflows were intentionally designed to strengthen the partnership between the two campus departments.

Already, members of these teams have begun to learn the best practices of others. Walk into a Workflow Team meeting and you might hear a metadata librarian talking about museum software. Sit down with the Metadata Team and the museum database coordinator might tell you all about archival finding aids. 

The Content, Metadata, and Workflow Teams have limited project charters — their mandate is to tackle specific use-cases and questions within the three-year scope of the grant. However, the investment in developing shared understanding and vision through teamwork has cemented working relationships that will thrive after the grant period ends. This will be critical to ensuring the success of the platform well beyond the initial development and launch.