This case study makes use of the following, which are described in more detail in the linked resources:
- Sharon Penfold BLMS Project Manager
- Andrew Preater (Senate House)
- Tim Fletcher (Birkbeck)
- Michael Oakes, (Institute of Education)
- Bernard Scaife, (Institute of Education)
- Colin Rennie, (SOAS)
- David Kay, Sero Consulting Ltd
- Ken Chad, Ken Chad Consulting Ltd
1. The problem
Senate House Libraries and the University of London colleges that make up the Bloomsbury Colleges group are looking to implement a ‘next generation’ library system solution to meet their diverse and complex needs.
At the end of 2012 they made a decision in principle to select Kuali OLE which is currently under development. Kuali OLE is a next generation system that is being developed under a community/open source model by an international group of academic library partners. The system will be run on a shared services basis by the University of London. This project is currently termed the Bloomsbury LMS, or BLMS. Work is ongoing with Kuali OLE and their development partner (HTC) about how the system will develop to meet the needs of the consortium libraries and what business process can be transferred.
a) A decision in principle
Making a decision in principle means that the consortium can engage with the provider early on in order to highlight specific and sometimes very local issues and ensure they are adequately managed.
b) Pain points – Shared concerns
A variety of library related systems, including library management systems (LMS) are currently in use in the member libraries. The institutions themselves are diverse and serve a wide variety of undergraduate postgraduate and research needs. The group identified a number of pain points that will need to be addressed. Although there was overlap, institutions also had specific local issue. The Shared concerns included:
- Taking colleagues with you can be hard and need good communication to allay fears. Member of staff grumble about their system until someone says it is being taken away. It’s especially important that we get people on board with a system that hasn’t been seen and is very early in its development
- We need good support for change (reflected sometimes in funding) from our institutions so that (non library) IT services, registry etc are properly engaged in the project and do what the library needs them to do to make it a success
- There still remains some uncertainty about the technology. What underlying systems (e.g. databases) are going to be used? System librarians will be most concerned about this as they are ones that need to work with the underlying technology like databases
- Global edit: how will it work? We want to remove the (current) annoying constraints around the ability to change groups of records. (i.e. change all occurrences in a record of ABC to XYZ)
- How will the library databases works across the consortium?
- What will the support structure be like-from manuals to help-desk, through to the wider user community etc—and what skills will we need?
- Will the migration be done module by module?
- Should we run systems in parallel between institutions and within them?
- how do we deal with (inevitable) loss of functionality
- How do we ensure critical functionality is met—what is the functionality we must have
- Notices and reporting: can we (should we) transfer system logs to the new systems so we can still do comparative reports with past data?
- We need to look at our workflows again—process re-engineering.
- What opportunities are there for shared practices?
c) Pain points – Issues with a particular institutional dimension
Consortium members are very ‘special’ institutions that may have local practices that are key to the particular value the library has to offer.
- How far will sharing a system lead to a loss of local independence?
- Will there be another (consortium) layer of bureaucracy to inhibit what we can do?
- We need to think hard about the extent to which our ‘local identity’ and service offering expressed via our own circ’ or acquisition rules for example.
- Local metadata practices. For example Senate House uses several classification schemes—and an in-house thesaurus (London Education thesaurus)
- Senate house is a (III Millennium) consortium (Institute of Advanced Legal Studies, Warburg etc etc) where institutions want to keep their own identity and have their own special aspects (like Warburg’s approach to authority records).
- Shibboleth on its own won’t meet our needs: all but around a thousand users are external (i.e. from partner institutions within the University of London –UL). That is one reason why we currently use our own proxy server—esp. for e-resources. Authentication needs to work across a number of systems. For example it drives the entry gates. Authentication has particular characteristics in a shared service such as Senate House. People naturally just expect it to work even if they are from other UL institutions. In particular academic staff expect things to ‘just work’
- Beyond Senate House authentication has a particular problem in a University of London context. For example defining what a university of London student is can be complex.
d) Identifying points of integration with systems outside the scope of Kuali OLE
The items listed here represent components that could be represented on the project ‘Function Palette’; for example:
- Physical access (turnstiles)
- Self service (SIP2 etc and RFID)
- Print systems
- Discovery services (e.g. VUFind at Birkbeck)
- Personal bibliographic software -Endnote/Reference Manager
- ‘People systems’ – students (and staff). This includes ID cards, payments information etc
- Published research –i.e. systems such as the Institutional Repository (IR) and e-thesis (Ethos)
- Archives-they are not integrated at the moment
- VLE—no system integration at the moment—but maybe it should be integrated?
- Exporting (bib data) for reuse-CURL/COPAC, VuFind, SunCat, M25 London list of serials, OCLC. At the moment the Institute of Education does linked data export
- Z39.50 service to e.g. M25
- Booksellers-FTP orders to (e.g. Dawson)
- EDI quotes and invoices (no-one does shelf-ready stock right now but Senate House about to start)
3. Methods Used
a) Business Ownership Matrix
The group used this model both to categorise (using the matrix) and then to differentiate (by colour coding) the systems and services potentially involved.
b) Shared Services Spectrum
The group used this model share aspirations and intent regarding ‘shared services’. Significantly discussion of the spectrum of options presented in this method provided clear reinforcement of previous analysis undertaken by the Bloomsbury consortium.
What level of sharing is wanted / required?
The consortium will operate as a fully share service in terms of:
- Shared practice and “Knowledge as a Service”
- Shared library system platform (database, backups)
What level of converged processes is wanted / required?
- Discovery-with shared index across institutions
- Shared cataloguing
- Collection development
- Shared user entitlements: Managing this (i.e. who is entitled to what (library) services) is complex- and would represent a big win for users and staff in terms of how they work with and perceive any new system
- Rules – e.g. local circulation and acquisition rules
4. Observations on Methods
In general the Bloomsbury Group felt that the exercise was useful in identifying a few new factors but more importantly in validated the work they had done to date. One member of the group commented that the work had ‘enabled us to reflect and refresh our collective minds’ and the output from exercise ‘ will be extremely helpful when we kick off the really hard graft early next year to make it happen’.