So you have decided upon the infrastructure - be it cloud, or on-premise - and the software - be it open source or commercially licenced. You need to also think about what happens to both of these over time and how you will continue to operate your digital Archive moving forward. The third part of this, that we’ve been sitting on for a while, are the people behind these systems - often called support.
It is critical that support is considered as part of a digital archiving system because - like any software platform - it should not be considered a static system. The practice of archiving is not static - as the new “Records in Contexts” standards demonstrate - and so your system should also change over time. Digital files - both those “born digital” and those digitised - will need to change formats over time and so too will your system need to change to enable them to be processed and turned into long-term preservation formats. At the very least as the digital security landscape changes over time your system must be upgraded and adapt for new threats coming into your systems.
No matter what kind of software you are talking about, like a car it needs regular routine maintenance and care, and will every now and then need a minor adjustment to keep it running optimally. Across the whole landscape of your system, you should expect to be making upgrades, performing maintenance and ensuring that your software continues to run optimally. It's important to realise this when you first implement a system, so you can factor in appropriate recurrent funding to make sure you're looking after it properly on an ongoing basis. This way you are solving small issues as they come up, instead of having to deal with a much larger (and more expensive) problem born of neglect.
The “shape” and size of your digital archive will determine the support that you need, and the number and type of people you will need to manage these components. So, for example:
- If you are using on-premise infrastructure - you need to have a way of managing the servers, networking, racks and all those systems, or be able to provide people who do that work access to this infrastructure (including aforementioned security skills),
- If you are using cloud infrastructure - you need to understand how the cloud provider you are using actually works, so as to understand how they work and what’s behind all those simple click-button operations that suddenly change your monthly bill,
- If you are using open source software - you will need software engineering and devops skills in order to undertake simple things like updates to the software to fully blown customisation of the system for your needs, and
- If you are using commercially licenced software - well, you’re going to need to have a good relationship with your vendor, as you typically cannot do any work on these types of software yourself.
So you will need a range of expertise depending on what you have chosen in the list above - and your organisation’s strategy. If you’re moving towards a strategy about longevity - something that is absolutely integral to all archives - then you will need to find ways for the relevant positions to be made permanent within your organisation should you choose to resource this all internally.
Another way to handle these resource needs is to outsource this work to other (appropriate!) organisations through a Service Level Agreement or SLA. This is the type of arrangement we have with a number of our archival clients at Gaia Resources, where they don’t have those internal resources, and have chosen to bring that expertise in from an external provider. This can be something that’s a temporary thing while you bring up the expertise internally - we have been working on that skills transfer with a range of clients - or it can be something more open ended.
A “good” SLA has certain characteristics:
- A clear scope - indicating what is included in the SLA, such as which systems are included but also as importantly - which ones are not,
- A clear statement of what constitutes a priority issue - this is a bugbear for any support organisation, and for customers under an SLA. It’s a place of tension where “I need it done today because it’s inconvenient to me” isn’t the same as “the business is completely stalled without this fix”, and so a clear understanding and agreement on priorities are important, and
- Enough time / resource to do the work - every SLA is something of a gamble; the customer wants it done as cheaply as possible, and every vendor wants to make sure that they can deliver a good service for the money that they are getting. So at a minimum the SLA should include an allocation for regular upgrades, as well as the unforeseen bug fixes and other issues that arise.
These all end up influencing the cost, so often your SLAs are tiered with different response times (how quickly you are notified of the issue or it is acknowledged) and resolution times (how long until it is fixed in the production system). The faster these times, the higher the cost.
An SLA is a key part of your overarching arrangement of how support is provided; but it is no substitute for a good relationship between the vendor and the customer. In the archives, the people that often create this relationship are the archivists that are versed in the digital space. Their involvement is critical - software engineers can deliver a wonderful system but it has to do things that the archives need to do, and you need to have the people that actually use the system to be involved in all aspects of the way your systems are managed and maintained - one of the reasons we have archival specialists on our team as well. After our recent trip to IPRES and PARBICA (see our last blog post) there are a lot of people firmly in both the archives and the technology camps - and there is a willingness for both sides to step towards each other, and close that gap.
So, feel free to get in touch with our team at Gaia Resources via enquiries@gaiaresources.com.au to discuss how we can help you and your team develop the skills you need - or provide them for you - to keep your archival management systems running smoothly. You can email us or start a conversation with us on our social media accounts.
Piers
Piers note: It was a long time between this post and the last two in this series - but the recent IPRES and PARBICA conferences gave us a real boost to get this series completed and out there - stay tuned for a revised version of this appearing as a white paper in the near future as well!