DRAFT – DRAFT – DRAFT – DRAFT – DRAFT

Introduction

The Catalog Request System (CRS) provides a web-based interface for patrons to request items from the catalog. It is integrated with payments/fines as well as with the RL Aeon system.

Governance:

This service supports patron requests for materials across multiple libraries.

Mission and Scope:

The goal is to have a web-based interface where patrons can make requests, see existing requests, see existing check-outs, etc. all from a "single" web-location.

Stakeholders:

John Pormann, Head, IT Core Services
Karen Newbery, Head, LSIS
ADS?

Owners:

Functional Owner:
Technical Owner: Derrek Croney is the most knowledgeable with CRS

Users:

Patrons who wish to make requests or check the status of their accounts,
Library staff

Maintenance and Sustainability:

Catalog Request System

Description	This is a Perl/Dancer2 web-app that runs on a VM.
Support	There is no support for this outside of DUL (home-grown app).
Community	There is no "community" for this particular service.
Strategy	The technology team is responsible for monitoring of security patches, etc. as well as any new feature requests.
Sunsetting	This app provides basic functionality for DUL that is not going to go away. Perhaps FOLIO will eventually absorb this functionality, but it is a ways out.
Risks	This app is written in the Perl/Dancer2 programming language which is not one of the "primary" languages in DUL DST.

Issue Submission and Escalation:

Any user may submit an issue via the IT Support @ Duke University Libraries web form. In response to the prompt What can we help you with?, specify Servers & Systems Operations.
Members of the stakeholder group may reach the technical team on Slack at #devops
The technical team will use Gitlab issue boards to track deeper problems or issues with the system (https://gitlab.oit.duke.edu/devops/devops-planning/-/boards/734)
Requests for staff to be added to privileged access groups must be done through through the main IT Support web-form (Service-Now)

Review:

Annual:

The stakeholders team will meet annually with the technology team to:

Review the existing service description, stakeholder list, support structure,
Close out any issues that may no longer be relevant,
Review the list of staff who have privileged access to the system,
Estimate any project efforts or needs for the coming year,
Review and adjust the list of users with access to the system, including both privileged and non-privileged access control groups, in Grouper/Group Manager as well as programmatic access.

This activity falls in the November-December time frame. Any actionable work will be documented and reviewed by DST-LT.

Servers/Service Details:

xxxxx

main VM running the CRS service