{"id":6687,"date":"2019-02-15T13:59:57","date_gmt":"2019-02-15T18:59:57","guid":{"rendered":"http:\/\/blogs.library.duke.edu\/bitstreams\/?p=6687"},"modified":"2019-02-15T13:51:59","modified_gmt":"2019-02-15T18:51:59","slug":"6687","status":"publish","type":"post","link":"https:\/\/blogs.library.duke.edu\/bitstreams\/2019\/02\/15\/6687\/","title":{"rendered":"Sustainability Planning for a Better Tomorrow"},"content":{"rendered":"

In March of last year I wrote about efforts of the Resource Discovery Systems and Strategies team (RDSS, previously called the Discovery Strategy Team) to <\/span>map Duke University Libraries’ discovery system environment in a visual way<\/span><\/a>. As part of this project we created supporting documentation for each system that appeared in a visualization, including identifying functional and technical owners as well as links to supporting documentation. Gathering this information wasn\u2019t as straightforward as it ideally should have been, however. When attempting to identify ownership, for example, we were often asked questions like, \u201cwhat IS a functional owner, anyway?\u201d, or told \u201cI guess I\u2019m the owner\u2026 I don\u2019t know who else it would be\u201d. And for many systems, local documentation was outdated, distributed across platforms, or simply nonexistent. <\/span><\/p>\n

As a quick glance through the Networked Discovery Systems document<\/a> will evince, we work with a LOT of different systems here at DUL, supporting a great breadth of processes and workflows. And we\u2019ve been steadily adding to the list of systems we support every year, without necessarily articulating how we will manage the ever-growing list. This has led to situations of benign neglect, confusion as to roles and responsibilities and, in a few cases, we\u2019ve hung onto systems for too long because we hadn\u2019t defined a plan for responsible decommission. <\/span><\/p>\n

So, to promote the healthier management of our Networked Discovery Systems, the RDSS team developed a set of best practices for sustainability planning. Originally we framed this document as best practices for <\/span>maintenance<\/span><\/i> planning, but in conversations with other groups in the Libraries, we realized that this didn\u2019t quite capture our intention. While maintenance planning is often considered from a technical standpoint, we wanted to convey that the responsible management of our systems involves stakeholders beyond just those in ITS, to include the perspective and engagement of non-technical staff. So, we landed on the term <\/span>sustainability<\/span><\/i>, which we hope captures the full lifecycle of a system in our suite of tools, from implementation, through maintenance, to sunsetting, when necessary. <\/span><\/p>\n

The <\/span>best practices<\/span><\/a> are fairly short, intended to be a high-level guide rather than overly prescriptive, recognizing that every system has unique needs. Each section of the framework is described, and key terms are defined. Functional and technical ownership are described, including the types of activities that may attend each role, and we acknowledge that ownership responsibilities may be jointly accomplished by groups or teams of stakeholders. We lay out the following suggested framework for developing a sustainability plan, which we define as \u201ca living document that addresses the major components of a system\u2019s life cycle\u201d:<\/span><\/p>\n