Who’s Flying the Plane? Navigating Multi-Stakeholder CMS Development Demands

Collection management systems (CMS) were once digital reproductions of paper catalogs, but now they are expected to provide much more than a catalog number and basic collection information. In recent decades, systems developed over centuries to manage physical specimens have evolved into unwieldy digital storehouses. Complexity in a CMS is introduced by stakeholders at all angles: collections staff, researchers, institutions, metadata standards, national and international priorities, digitization efforts, and technologists. Here we explore problems and opportunities through the lens of Arctos, which has been part of this digital evolution as both a CMS product and a user community for nearly 30 years (Cicero et al. 2024). In 2024, Arctos membership is international and includes 57 institutions with 330 collections managed by 270 active database users how can it do so in sync with the broader community?Cicero et al. 2024). Complexity—even when only considering Arctos’ internal stakeholders—is inherent to the data model. Agents, or the people and organizations who interact with collection objects, provide a useful case study. As a nascent digital system in the 1990s and early 2000s, Arctos’ model was groundbreaking in its decision to treat agents as entities with their own metadata that could be shared across collection objects. Paper catalogs did no such thing. In the past few years, the Arctos community has seen value in fully utilizing and even expanding Arctos’ ability to capture and connect primary source and biographical information about agents. The biodiversity collections community is building momentum behind sharing people data in more and better ways (Groom et al. 2022, Weeks et al. 2024), and the broader museum and academic communities are evaluating how our data need to change in order to be equitable and inclusive (e.g., by developing approaches for handling diacritics). As Arctos continues to respond to boundary-pushing development opportunities, At present, the Arctos community is continually balancing needs between diverse internal stakeholders. Conflicting interests are not necessarily bad; they exist because Arctos is capable of managing complex information, and the Arctos community recognizes that consensus-building presents challenges (Cicero et al. 2024). Turning tensions into development productivity requires a framework for decision-making, and processes that facilitate the alignment of expectations. As much as Arctos has been developing data infrastructure over the past two decades, it has also been developing community processes. Arctos committees, working groups, subcommittees, and staff all meet regularly and follow well-intentioned social norms. There is a GitHub space to organize work and have discussions. A handbook documents shared knowledge. Yet despite such good and continual progress, in today’s under-resourced landscape it still feels like the Arctos community is building the plane while flying it, with a route that changes based on the prevailing winds. This is in part because CMS teams are often skeleton crews. Arctos has only two full-time staff (a lead programmer and a community coordinator), plus one part-time database administrator. In addition to increasing overall staffing, roles that explicitly support structuring and maintaining systems to help developers understand and balance the expectations of users are required. Such roles may be described as “product manager,” “project manager,” “user experience manager,” “business analyst,” etc. At the intersection of CMSs, institutions, and bio-geodiversity communities, one might hope to find paid staff in such roles, driving globally-coordinated development. T he global bio-geodiversity data community needs people whose time and expertise are dedicated to bridging physical collections with digital information systems, connecting experts from one field with experts in another, and developing basic infrastructure that can benefit a diversity of users. What could be accomplished if there were more people working at this intersection, and working from a human-centered design perspective (e.g., see examples from 18F, the United States’ digital.gov, the United Kingdom’s Central Digital and Data Office)? The shared needs of collections staff could be translated into global development priorities, e.g., by canvassing the community at large to define stakeholder requirements for a given request to add or modify a term in one of the community standards. Development teams, including those within and external to CMS domains, could have time to collaborate, identify opportunities and reuse applicable resources. For example, the Database of Global Administrative Areas (GADM) is a resource that Arctos leverages for decision-making and data quality related to geography. Arctos is designed to benefit from the expertise of external authorities, but cannot do this well without people-power dedicated to reviewing and developing a solid understanding of each resource, and to collaborating with external resource developers. Technical progress cannot hope to succeed without centering the people involved. From inception, the idea of a CMS was centered on the individual users and local institutions who provide day-to-day care of natural science collections. Here, we explore methods for prioritizing the human side of CMS development such that it maintains that core purpose, while also connecting to the extended vision of national and international collaborative networks, data flows and decision processes.