Skip to content

Q2: Decommissioning Authorisation guidance

SamCallaghan edited this page Nov 10, 2021 · 7 revisions

1. Purpose of the Decommissioning Authorisation document

Introduction

In an ideal situation, future planning for a digital research output is incorporated into the initial planning before the project has begun. The RSE team has integrated archiving and sustainability plans into its SDLC by:

  • Adopting a more limited technical stack which allows for longer-term support;
  • Providing for ongoing support, using standard system and data life-cycle maintenance.

This helps ensure that the future of the digital output has been considered beyond the active periods of the SDLC. However, in many cases (especially with respect to legacy projects) consideration of the future of the digital output can often occur towards the end of the SDLC. Regardless, documentation of the future of a digital output post-active development will be required.

As decommissioning approaches questions to consider are:

Topic Questions
Ownership * Who are the Principal Investigators?
* Are they still affiliated to the institution at which they began the project?
* What does this mean in the context of possible institutional support?
* What does this mean in the context of institutional control?
* If the Principal Investigators are unknown or unable to be contacted who has responsibility to make decisions regarding the digital output?
Impact and scholarly value * What is the content of the project?
* What are its audiences? How large are they?
* What impact can this have on fundraising?
* What impact can this have on institutional reputation/brand if a project can no longer be supported? How might this impact be mitigated?
Future research * What are the Principal Investigators’ future plans for the project and the research they undertook through it?
* Depending on content and their requirements, can the needs of future research, citability or reference be met by decommissioning options for the project?
Funding * What constraints did past funding have on the digital output?
* What options for likely funding are available for continued hosting of the digital output?
* For further development of the digital output?
* Who has responsibility for applying for ongoing funding and what are the timelines?
Security
Technical systems and maintenance

Once external funding of the digital output comes to an end further funding (either internal or external) needs to be found to continue hosting. In some cases further development is needed to upgrade technical components. If this is not possible, the digital research output may need to be decommissioned, in a number of ways.

The purpose of documenting decommissioning authorisation is to capture information regarding:

  • Who was responsible for the creation of the digital output of a project, as well as its purpose and duration of activity;
  • Who has responsibility for the decommissioning of the digital output;
  • Details regarding the process by which the digital output was decommissioned.



2. Completing the Decommissioning Authorisation

Header table

The table can be found in the Decommissioning Authorisation template document.

2.1. OVERVIEW

This section includes a project overview; this can come from Terms of Reference, Product Quote or SLA. If these documents are unavailable a project overview can be taken from a project's 'About' page or wherever appropriate. This narrative description describes the purpose of the project and is an important source of information if the digital output is to be held in institutional minimal storage.

2.2. BACKGROUND CONTEXT

This section includes any background information that is relevant to the project, including the rationale for the decision to archive or shut the site down. It is important to capture which options were discussed and all decisions made to provide context for those in the future who may have the responsibility for the ongoing storage of decommissioned projects.

2.3. SITE SPECS

This section includes any relevant specifications connected to the working specs of the site at the time of archiving e.g. software version, disk allocation, security issues.

2.4. SITE FUNCTIONALITIES

The decommissioning lead would choose a minimum of three screenshots to include in this section to represent the core site functionalities/interface (e.g. homepage; search page; browsing) and include minimal descriptive captions. This information allows those without access to the digital output themselves to understand, at least to some extent, the functionalities as well as look and feel of the output.

2.5. REQUIREMENTS

This section includes any special requirements in regard of archiving. For example:

  • Formats required for depositing?
  • Individuals requiring post-decommissioning access? And the process by which this may be authorised?
  • Individuals or organisations, other than the noted contacts, that require notification that the digital output has been decommissioned?

2.6. DECOMMISSIONING SOLUTION

For a sample tick list see the Decommissioning Authorisation template document.

2.7. SUPPORTING DOCUMENTATION

This section stores evidence of authorisation to archive: e.g. email confirmations (convert to PDF and store in cloud storage), and any links to your issue-tracker tickets confirming agreements, other relevant communication, including details of unsuccessful attempts to contact the project partners (with dates).

In addition, wherever possible, this section should include a link to the original awarded project proposal, converted to PDF and saved in cloud storage. Note that redaction is required for personal information included (should be done on PI/proposal holder side).

2.8 AUTHORISATION SIGN-OFF

Finally, the document records who authorised the decommissioning, their role in relation to the digital output and when the authorisation occurred.

2.9 DECOMMISSION SIGN-OFF

Following completion of decommissioning of the research digital output and documentation of decommissioning authorisation, the document itself requires sign-off from an RSE Project Manager and the organisation director or department lead.

Sources

  1. Smithies, James, Westling, Carina, Sichani, Anna-Maria, Mellen, Pamela and Ciula, Arianna (2019) Managing 100 digital humanities projects: digital scholarship & archiving in King’s Digital Lab. Digital Humanities Quarterly, 13 (1). ISSN 1938-4122 http://www.digitalhumanities.org/dhq/vol/13/1/000411/000411.html
  2. Archiving and sustainability: KDL's pragmatic approach to managing 100 Digital Humanities projects, and more... https://www.kdl.kcl.ac.uk/our-work/archiving-sustainability/

Clone this wiki locally