Bloomsbury LMS Kuali OLE project critical success factors
•Download as PPT, PDF•
1 like•721 views
I presented this talk on the project critical success factors for our implementation of Kuali OLE at Senate House Libraries, University of London for a SCURL event titled at the University of Edinburgh on 12th April 2013. I co-presented with our project manager, Sharon Penfold. My sections of the talk are here - I describe 1) the reasons for choosing an Open Source / Free Software LMS; 2) our reasons for choosing Kuali OLE in particular; 3) the actual work done at Senate House Library towards OLE implementation so far; and 4) the project success factors for technology in particular and staff workflows and culture as well. My presenting style is very light on text - you want to look at the notes in the downloaded version.
Recommended
More Related Content
Viewers also liked
Similar to Bloomsbury LMS Kuali OLE project critical success factors
Similar to Bloomsbury LMS Kuali OLE project critical success factors (20)
More from Andrew Preater
More from Andrew Preater (20)
Recently uploaded
Recently uploaded (20)
Bloomsbury LMS Kuali OLE project critical success factors
- 1. Bloomsbury LMS project success factors Andrew Preater, Associate Director, Information Systems and Services SCURL, University of Edinburgh 12 April 2013
- 2. Open Source
- 3. Open Source Philosophical fit to HE
- 4. Open Source Best of breed software
- 5. Open Source A pragmatic choice
- 8. Kuali OLE A campus-wide, enterprise system
- 9. Kuali OLE By and for academic libraries
- 10. Kuali OLE Not a DIY option
- 11. ‘The grunt work’
- 15. Discovery
- 16. Discovery model Discovery Discovery SHL web SHL web Digital Digital BLMS BLMS Archives Archives content & content & ePrints ePrints
- 17. Discovery model SHL website & Discovery SHL website & Discovery Digital content Digital content BLMS including Archives BLMS including Archives & ePrints & ePrints
- 19. Success factors in a box: technology and more
Editor's Notes
- Not to a ‘religious war’ between Open Source and proprietary - but do want to discuss why OSS is a good fit for libraries especially in HE.
- Collaboration is fundamental in the HE sector and particularly within libraries. Older concept of Free Software originating in HE. Open Source or Free Software – doesn ’ t matter that much. Blog post with more: http://www.preater.com/2012/10/15/free-software-and-cultural-change-at-libcampuk12/
- OSS is (often) the best! Proprietary suppliers use OSS themselves. Why? It represents best-of-breed software that is stable and well-supported, and importantly is flexible and free to use. OSS is licensed in a way that allows development and may be used for any purpose. It is difficult for software suppliers selling systems based on Open Source to argue against it, using it in their products can be seen as vouching for it and also undermines vendor FUD. 1 example: lots of projects use Apache Lucene and Apache Solr including in the OLE document store.
- A pragmatic choice in terms of mitigating certain risks: Closed vendor being bought out by another LMS vendor and forcing you on a migration path. Secures the future of the system in case of being bought out by capital investors. Vendor source code might be held in escrow – but how useful would that be to the average library if they needed to use it?
- Marshall Breeding on the LSP concept: “ To make up for functionality absent in their core integrated library systems, many libraries implemented a cluster of ancillary products, such as link resolvers, electronic resource management systems, digital asset management systems, and other repository platforms to manage all their different types of materials. The new products aim to simplify library operations through a more inclusive platform designed to handle all the different forms of content.” http://www.infotoday.com/cilmag/sep11/Breeding.shtml
- In HE the the LMS can be seen as a box sitting in the corner - perhaps even a corner of the library itself. A weird system that works in a weird way and doesn’t command too much attention from IT or the broader university. Michael mentioned the requirement for an enterprise approach at Penn – I agree, and argue LMS and resource discovery are about enterprise information, and should be seen as a key system enabling learning and teaching, and research . The nature of the data used means these systems are business critical for our HEIs.
- As Michael mentioned the focus is on what an academic / research library wants and needs in a system. Kuali foundation ‘ gets it ’ in this respect – but as you ’ ve seen the functional experts – librarians and library workers – sit within a foundation that includes development expertise in analysis, consultancy, and project management. This means you avoid pitfalls that you can imagine if I asked you to picture a library management system built by librarians. :)
- There are historical examples of OSS implementations in HE that are not so good. How do we sustain development? This is a real concern for anyone who has supported and maintained OSS and HE. Also there is still a myth we ’ re describing a system we will download, install, and support ourselves. This is not the case with OLE. Yes - in some cases this can be a good approach for testing and prototyping as it lets you get a feel for the software, eg. test instances of Vufind by BLMS members has build good knowledge and collaboration with very little money spent. Also For some purposes we do talk about ‘ building it ourselves ’ but we mean as part of a partnership with a software developer - not me or a developer in house hacking on the OLE codebase.
- Outline of what Sharon described as the grunt work – things we did in SHL and the college systems group to actually do the work.
- This is the big one for us. Working with subject matter expects in the libraries to develop a spec that describes what we want. Using Atlassian Confluence as a tool for sharing and collaboration. This is not open source software… also I ’ m presenting on a Mac running OSX. :) Everything in the SHL Confluence pages on OLE was open from the beginning – every systems librarians meeting, every conversation with the project manager long enough to take notes. Part of this is related to gaining buy in…
- We have a stable and mature workforce including staff that well remember our original automation, and our initial move to Innovative ’ s Innopac system in the 1990s. There can be a tendency to think ‘ I ’ ve seen it all before ’ . Working with staff to actually do the work creates buy-in. Openness: everything I have written for the project is available to staff. Communication: regular updates from me and others at meetings, presentations, etc.
- Including: University senior managers – particularly our COO / Secretary. (Note that OLE exists as part of a Kuali ecosystem including financials, student records – lots of potential for additional Kuali components as a good choice in future.) University IT – essential from early on, so much of our LMS success hinges on IT infrastructure like network and this will only become more key if we cloud host. Records managers especially for data protection issues. University procurement team
- A project runs alongside the BLMS to replace our current ‘ discovery potpourri ’ with a next-gen discovery layer.
- The goal for BLMS initial implementation. Discovery layer provides search and finding across LMS holding, ePrints digital content and archives. What you see here is pretty much achievable now if we a) implement a discovery system like VuFind, Blacklight, Summon, etc. b) upgrade Adlib to handle metadata harvesting.
- The long term goal is more like this. Ideally we would include archives cataloguing functions in OLE. We remove Discovery as a siloed destination, rather the website is the place you go to find. Practical examples exist now with integrated websites and library catalogs driven by a back end LMS server that is not otherwise used by end users. I have included ePrints along with other digital content as an example of hosted digital content we would include alongside “things to be discovered”.
- Including reclass and ‘ tidying up ’ legacy bibliographic data. Much of this goes back years but we ’ ve not been able to approach it except under the aegis of a ‘ big project ’ with central funding approached in a way that is engaging to university senior management. Includes: Reclass of our open access stock to Library of Congress from Bliss (I think Bliss class is an early form of gamification as finding anything is like a tresure hunt…) RFID tagging of the same Alongside moving our existing off-site store to a new facility
- A cloud hosted LSP needs a stable and robust IT platform. This is based on enterprise IT approaches rather than from libraryland. Central role of UoL in collaboration across our colleges – a lot rides on this working properly and systems cannot go down willy nilly.
- Certain essential campus systems to interop with: Finance – Agresso, essential to have this link. Student records (not at SHL but in our distance learning arm, University of London International Academy). Online sales via a WPM shop.
- LSP is open and extensible for future work. Some of the LSP functional spec is a bit aspirational – but we know we can build it in to OLE later. Much of this most immediately relevant for our work on discovery. Michael spoke about development and ‘ building it ourselves ’ earlier. I wanted to reiterate this importance of actually being able to do this with OSS, and particularly working with a development partner to do coding, whereas often with vendors suppliers you can ’ t even buy it.
- An opportunity to review all of our library workflow and processes. A business analysis process that looks at where we have practises often limited or designed around limitations of the current LMS.
- Staff are becoming more daring in their thinking. The scale and scope of the OLE project has given us confidence that almost anything can be done. As Mike has mentioned: the LSP is in part about repositioning Library staff, and the role of those staff as ‘ university-wide agents ’ for change. Library is the original shared service in HE: we ’ re building on that.
- Contact us: [email_address] andrew.preater@london.ac.uk or @preater BLMS project blog: www.blms.ac.uk