Recent Posts

In her most recent blog post, Hannah wrote about our approach to Project Electron’s proposed systems integration architecture. One of our goals with Project Electron is to support the flow of data about digital materials between our systems and getting valuable information to researchers in new ways. Supporting data in motion is integral to Project Electron’s success, and while Hannah and Hillel have been hammering away at creating a comprehensive overview of the microservices architecture, I’ve been working with the entire archive center to develop a draft data model for discovery and display of born digital and digitized materials. If, as we’ve been thinking, Project Electron is about creating infrastructure to support data, a data model will in turn act as a blueprint for that infrastructure. Data models are tools we can use to communicate and define how we want data to move between systems, and we think understanding how our data will move throughout our systems to our researchers is vital to the success of the entire project.

I recently attended the IA Summit 2018 in Chicago. This was my first time attending the conference, which brings together a mix of information architects and design-related professionals, and I came away with some fresh perspectives on my work here at the RAC. The summit consisted of both practical talks about specific methods and tools, as well as wider reflections on ethical considerations and trends in the field.

The underlying architecture that enables the movement of data between systems is a key aspect of Project Electron. In our project values, we talk about components as modular and generalizable, independently deployable and  flexible enough to accommodate integrations with changing systems. The project value to “support data in motion” recognizes the strength of duplicate and distributed data, and articulates Project Electron’s approach to systems as points at which humans interact with or manage that data. All of this is to say that our strategic decisions relating to choosing an approach to system architecture, particularly with regards to systems integration, is essential to the project’s success and sustainability. In this post, I’ll share some of our current thinking around the various systems integration models and our considerations in choosing an approach that will enable these integrations of archival applications.

I’m just back from this year’s Code4Lib conference, held in Washington D.C. As I’ve written here before, it’s an event that is, without fail, productive, provocative and exhausting. Over the years, the things that have stayed with me from the conference have changed (arguably the focus of the conference has changed as well) from technological tools for solving problems to values and frameworks for thinking through problems.

In the last Project Electron update, I discussed the benefits of user interfaces as communication tools during development. This month I want to share more about the archival functions that those user interfaces enable in the application, which has been the focus of our recent development work. Specifically, I will share how the application enables appraisal and accessioning functions, as well as managing structured rights statements.