Sustainability for Research Infrastructures

Learning outcomes

By the end of this section, you should be able to:

• Be aware of competing definitions and paradigms for “sustainability”
• Know what the goals of a sustainability plan should be, and what limitations you will face
• Contextualise your understanding of sustainability within the internal and external environments of any research infrastructure or project development

Sustainability is a word that you hear everywhere in speaking about digital research infrastructures and projects.  But what do we really mean by it?

The answer is that, yet again, what we mean by sustainability will largely depend on what from perspective we view the infrastructure.  If we view its data as its most important component, then we might be likely to view standards and the implementation of good data preservation policies as the keys to sustainability.  If we view it largely as software, we would look at the technical underpinnings that make platforms easy to keep running and migrate.  If however we view the infrastructure as an organisation, we may instead be thinking of funding models as the key to long term viability.

Good work exists coming from all of these perspectives, but how do we resolve them into a single approach to sustaining our hybrid digital work, in particular when this work has expanded to reach an infrastructural scale?  And what about the things we build in an infrastructure that are not embraced by these definitions, such as communities, or the tacit knowledge we may not know how to share.

From an infrastructural perspective, the definition of sustainability must start from the perspective of reuse:  how we engage users and promote their adoption of the tools and knowledge we make public is the goal that any other sustainability considerations (where we host, what we preserve, how large a staff we need) must support.  When our users and their needs are diverse, however, then we must also view what we have built not just as a monolithic final product, but as a confederation of mutually supportive components, some of which may be more useful to certain users than to others.

The first step to sustainability, then, is to understand your project as your users do.  This may involve looking at a series of different classes of assets, and potentially planning for their sustainability in different ways, for example making certain technical components available as stand along tools, or sharing data back with the institutions it was federated from.  What kinds of assets you find will vary, depending on the kind of infrastructure or project you are, but it will be likely to include categories such as tools, services, data, knowledge, and networks.

Second, sustainability must be viewed as a process, not a product.  Self-knowledge and user-knowledge must be brought to a convergence, if value is to be defined in a final document.  Stakeholder meetings held while the project is still in mid development are a good way of building this awareness, as is building partnerships with bodies that represent your users or other ‘critical friends.’  Data management will also be a key element of the foundation you build on, and should be a central part of planning for sustainability.

Third, openness is a key to sustainability and reuse in the current climate.  Implement common standards that will allow your data to be reused, share your software so that is can be improved by others, deploy a modular architecture so that difficult components can be removed or deprecated. These measures will help your users bring you with them as their needs and environment change

Fourth, be sure to share as much knowledge as possible as widely as possible, even and especially when that knowledge may be at risk. Knowledge that is ‘at risk’ is held in a format that may not support wide visibility, possibly in the form of a project-specific format (which may or may not have an easy path for dissemination to peers outside of the project) or indeed it may be the tacit knowledge your team has built up.  In particular in this last case, it may be useful to occasionally ‘audit’ this knowledge, to ensure that experiences, and indeed failures, are documented and shared with the wider community.

Finally, be realistic about ‘long term’ sustainability.  For a technical platform, 3-5 years availability may be the best possible window.  If the project is of value, it will need to be revisited and rewritten within that time frame, a process that is not so much sustainability as a new active phase.  For this reason, however, it is important to keep the most active members of the project development team engaged and committed to the project’s need to ‘evolve and involve’ in that time frame.

This lecture presents more information on how this model was rolled out in the CENDARI project.

You can view and download the slides for this section from our SlideShare profile, or in our Training Resources section