This case study makes use of the following, which are described in more detail in the linked resources:
David Kay and Owen Stephens from the LMS Change project visited the Open University on 13 December 2012 to work with
- Claire Grace – Head of Content and Licensing
- Richard Nurse – Head of Digital Services Development
- Hassan Sheikh – Head of Systems Development
- Chris Yates – Business Systems Manager
1. The Problem
a) The Setting
With the impact of changes in funding UK HE, there is a huge pressure on HE institutions to make savings in both staff and non-staff costs. Meanwhile the prospects for outsourcing IT now encompass a range of options from tin and connectivity (IaaS) to fully supported cloud-based implementations of core applications (SaaS). As a result, moving systems to cloud based solutions is a direction many HE libraries worldwide are considering.
OU Library Services has already planned in principle to move its LMS and Open URL resolver to a hosted solution in 2013/14 and has decided to replace a permanent systems librarian post with a two-year contract post to cover the period of transition to a hosted solution.
It is essential therefore that the management team fully understands the staffing implications, costs and the risks of such an approach. The team also wants to consider whether other systems, such as Knowledge Bases, Proxy servers, Repository and internally developed Digital Library services could also move to hosted/cloud solutions, either at the same time or in the short-to-medium term.
b) The Challenge
Managing the current locally hosted library systems with a small in-house IT team is increasingly challenging as there is ongoing pressure to reduce both the staffing and the maintenance costs of these systems. However
- There is a complex mix of systems from several different suppliers and managing these separate systems is increasingly challenging;
- There is also a number of internally developed applications to be maintained;
- Systems staff are responsible for a range of tasks across these systems.
Even though the load on the systems team can be broken up in a number of ways, it needs to be understood which options may lead to tangible savings. The move to external hosting for some systems may not sufficiently reduce the volumes of work in two respects:
- There will be a continuing requirement for the same skills to maintain other systems;
- For the outsourced systems, there are tasks that do not necessarily travel and still need to be performed locally even though some move with the system.
c) The systems in scope
The following systems are at the heart of this change scenario:
- Library Management System (Voyager)
- Open URL resolver and Knowledge Base (SfX)
- Remote access proxy server (EZProxy)
- Discovery system (EBSCO Discovery Solution and already cloud-hosted)
- E-Resources Management System (in-house system)
- Institutional Repository (Eprints)
- Digital Library (Fedora-based – under development)
However the total list involves almost 30 applications (see Section 3) to be managed by the library team, of which around 60% are user-facing and 40% are administrative.
In two hours discussion we examined this problem space from a number of operational angles, (putting aside issues of principle, such as location of data, to be covered elsewhere) including:
- Breakdown of ‘systems’ tasks involved
- Mix of staff required to perform so-called ‘systems’ functions
- Data and real time operational dependencies between systems
- Available vendor service offerings
This discussion led us to the need to map and cross-reference roles, loadings and systems:
- What roles are performed?
- How large are these roles for each of the systems in question
It became clear that modeling these relationships would provide ‘ready reckoner’ view of the total resource / skills commitment, enabling the team to ask ‘What if’ questions about the impact of outsourcing individual or multiple systems and about the tasks that remain versus the applications that remain.
The recommendation arising beyond our meeting was to populate the model with numeric values (not yes / no or large / medium / small) so impact could be measured. It was recognized that these numbers would be useful as guides even if simply indicative. For example the total human resource in the model could add up to a notional ‘100’ or to the number of systems FTE being deployed by the library team.
3. Methods Used
As the dynamics of the problem emerged, the group evolved a way of modeling staffing commitment to assess shared service opportunities. In the resulting ‘Requirement v. Resource Matrix’, each OU library system has a row and is categorized according to:
- Internal / External? – Who is the user / client
- Outsourced? – Is it / could it be outsourced to a specialist (i.e. SaaS)?
The key to incisive analysis was to agree a high level breakdown of work categories involving systems librarians. As per the columns in our spreadsheets, we agreed:
- System Administration
- Upgrade / Configuration
- Data Operations
- Development (e.g. Scripts)
This is the spreadsheet we constructed together, capturing immediate perceptions of loads and actors for each application.
The broad / generic characterisation of load (e.g. H/M/L) is well suited to filtering within the spreadsheet and is therefore good for identifying subsets; for example, here are systems where the library has the full System Administration responsibility that also involve a Webmaster role.
However we recognized that an indicative numeric would be also be important address other aspects of the decision-making. For illustration only, and using fictitious values, the same matrix is populated to show the distribution of 2 FTE systems staffing (represented as 432 days). When the data is sorted by ‘Total Days’, the nature of the ‘long tail’ systems problem is highlighted, with important messages about the likely impact of vendor systems outsourcing.
4. Observation on Methods
The mapping of systems and roles in the ‘Requirement v. Resource Matrix’ is nothing more than a standard approach to resource planning. However this approach seemed particularly useful in establishing the rationale and decision criteria in a complex and multi-faceted area such as outsourcing / cloud-sourcing:
- To obtain rapid scoping of the problem space
- To identify options and issues
- To see the resourcing consequences of superficially ‘easy’ moves
In this respect, it is important that:
- The team is comfortable using broad-brush indicators of scale, whether numeric or codified
- The team shares a common understanding of the meaning of each column (which was a problem in our exercise, which as a first pass involved a lot of improvised thinking)
- Columns are introduced that would enable early differentiation – such as ‘Internal?’’
- That both the numeric and non-numeric views are developed