Some rough notes about the potential of ‘digital preservation as-a-service’…
Digital preservation as-a-service (DPaaS) is a concept that could potentially allow many more users to satisfy the need to maintain ‘records’. Be those records in government, in another so-called GLAM institution, or one’s own personal memories and artefacts.
DPaaS makes sense on a number of levels as it enables the sharing of some very expensive infrastructure and individuals (storage, backup, delivery servers, software maintenance, engineers).
Those savings could be significant but I’m not aware of any single exemplar of the complete DPaaS infrastructure operating out there right now.
My instinct is that this is because one does not simply do digital preservation.
But that’s an overly dramatic simplification.
It was this week that as I was reading Rhiannon S. Bettivia‘s paper on designated communities in OAIS, and Stacie M Williams and Jarrett Drake‘s paper on a post-custodial people’s archive in Cleveland that I managed to make my instinct a little more concrete.
These two papers alone will give you plenty to chew on when considering the very real socio-political tensions involved when looking at the implications of the DPaaS proposal at scale (those aren’t discussed in this post).
Let’s talk conversation…
In the progressive post-custodial formulation of Williams and Drake you have the community organiser in partnership with the archivists. In a custodial formulation you may have the archivist in partnership with a government agency.
Should either invoke DPaaS then you introduce the service, but how are the efforts of the digital preservation service measured, monitored, and kept in check?
In my institution there’s always a third voice. A conversation often occurs around three main areas:
- Preservation Management
- Someone who deeply understands the goals of digital preservation
- Someone who deeply understands the goals of the archive, its remit, and the customer
And this works well.
You have engagement and a feedback loop that take you toward an agreed preservation solution…
Take preservation management as an engagement. If the digital preservation analyst spots a format that is at risk, and then says, let’s convert it to an ASCII derivative; then a discussion can be had between the three parties, or translated across the three parties and a decision can be made that satisfies the main stakeholders. We may or may not decide to take this approach.
In a service construct this changes.
The digital preservation expertise sits service side and now has to deliver a solution to multiple other institutions, and those institutions have to deliver that solution to their own customers. Can this strategy fit all, and, using the designated community definition still:
Ensure that the information to be preserved is Independently Understandable to the Designated Community. In other words, the community should be able to understand the information without needing the assistance of the experts who produced the information”
As well as satisfying the archival notion of trust and authenticity of the record, for that community.
What should DPaaS look like?
I drew some diagrams to help me think about the permutations. (The various circles below either represent a role or institution).
The first diagram is a simplified version of how we might setup digital preservation at present.
In a DPaaS situation we may begin by replacing the technical infrastructure with cloud services (we do see institutions employing cloud based services like this…).
But then we can start exploring more exotic combinations of DPaaS all the while keeping in mind our growing user base.
This is where I think we may begin to fall short. At this point we may have to find common solutions for each customer, but this may be difficult when trying to:
- Deliver different mechanisms and tools for transfer and ingest
- Deliver different approaches for addressing preservation issues on ingest
- Fix preservation issues post-ingest
- Provide different access copy formats (and generation mechanisms)
- Create flexibility of arrangement and description across multiple catalog systems
- Provide alternative approaches to preservation management that best match an institutions, and community requirements
- Communicate meaningfully and compassionately about preservation and archival requirements across all users
We won’t simply find efficiency through incorporating new metadata handlers and extractors.
We have to think about how we scale DPaaS.
I don’t think these diagrams are novel at all. They represent a pattern we see often in the transferal of cost. Hopefully they help us to question where that cost should be transferred to. Where it makes most sense to scale.
From the archival perspective, we have to ask, where it makes most sense to achieve a result most suitable to our customers.
As digital preservation as-a-service solutions become more common I am optimistic about its potential, but as always ‘buyer beware’. I don’t think it will be a silver bullet. If there is any part of the solution that may be undersold, then for me it is the need to still develop digital literacy capability in your organisation to become more informed consumers – to keep your provider in check – and to create a fulfilling and rewarding relationship via feedback loop that can benefit all parties involved and all users of the same service.
I wrote this blog on the back of a chat today to help me put some of my thoughts together in a useful way for future other conversations. There are a number of assumptions here and I’m still not sure if it’s actually a ‘thing’ per se. The development of DPaaS may prove to be quite organic and intuitive and we’ll see organizations naturally want to adopt a ‘diagram five’ like approach.
My own takeaway as I hit publish and sign-off for the evening, is that, if DPaaS is going to take off, it does look like it will be a significant undertaking for the provider. Initial cost-savings for the consumer may not be so great either as I do feel staff and training will be most important. But we’ll see…
I want to believe.