KDUK – 2014
Student, Research Management, Finance (and a touch of library)
Following the hugely successful 2013 KDUK, Kuali returned to Bloomsbury to show more of the potential for the UK HE sector. Keeping your money in your service is a major selling point – offering greater flexibility to adjust to changes in demands in a way that is just not possible with vendor driven systems.
2013′s KDUK focused on OLE – the Open Library Environment.
2014′s KDUK is the year of Kuali enterprise systems, which are all operational and delivering the promised benefits.
The US Kuali community is extremely active and supportive, welcoming other partners whatever their location – including South Africa and the UK.
Coventry University have led on bringing the wider Kuali suite to KDUK 2014, collaborating with the Kuali Foundation, JISC and SOAS to do so.
SOAS is the UK and European lead on implementing OLE and has been working engaged with the OLE community since November 2012. In terms of Kuali’s wider potential, OLE is underpinned by the Rice middleware and Kuali Finance – which is the most mature of the complete suite.
KDUK – 2013
Votes of appreciation go to all who presented, organised and not least, attended Kuali Days UK in October 2013.
The event saw over 120 delegates and speakers meeting at Senate House, University of London to hear more about Kuali as a suite of student and business applications, not just the OLE library system.
Highlights included the Vice President and CIO of the University of Maryland, speak about Maryland’s use of Kuali Finance – emphasising the underlying robustness of the system, which in turn underlies Kuali Open Library Environment.
Paul Webley, Director of SOAS, opened proceedings.
(Note: this write up is of KDUK, not the Bloomsbury LMS project, so the points highlighted are generic to the wider sector.)
Themes appeared during the 2 days that are relevant to the sector, next generation systems and open source, not just Kuali and OLE:
Elephants in the room
Summed up by John Robinson and tweeted by Mark Hughes from Swansea the elephants on the sidelines are:
Money: No surprises, there is still a significant resource requirement to implement a new LMS on a large and complex scale. This is being proven to apply to next generation vendor systems, but the profile of skills and money changes against open source.
Security: An area that the public sector has not traditionally been as alert to as you might hope, including student record systems. The levels of interoperability that come with OSS in particular require robust and professional security testing. If your IT department is sufficiently resourced and/or focused on this, then their support is especially welcome – otherwise
Vendors: Not entirely welcoming as expected, but a balance is required in the marketplace and is more than possible to achieve, partly based on risk appetite of the institutions concerned and their approach to student experience.
Procurement: Linked very much to risk appetite and the partnership-based approach of an institution’s procurement capability. Legal, testing and governance frameworks can support a balance here – which will still pay for themselves
Resources to implement
One aspect explored through a few questions was how many people are required to implement and support OLE.
Whilst Robert McDonald and Mike Winkler shared their respective staffing and skill-sets, Indiana and Pennsylvania are full-on development partners.
This latter applies to all the US teams, so they have Java programmers amongst other deeply technical resources.
They also have considerably more bodies on the ground than could ever be expected in UK academic libraries – without a similar 4-year programme totalling many millions of dollars of direct investment and the same again in staff.
GBV and HBZ, consortia in Germany who were also presenting, have a considerably smaller team which is still technical – and again, they are looking at OLE as their own development programme.
At present, there is no classic operational implementation of OLE – Bloomsbury will be the first without having been a full-on development partner.
If Bloomsbury were to go ahead without their own commissioning partner, HTC, they would indeed need to build up their own team. Once operational, the shared service will provide support for the OLE system. The exact shape of this will follow once its operating company is set up, but this is an important step in bringing library systems off of the ‘box in the corner’ and into enterprise IT.
However, next generation systems of all types require specialist implementation services – whether from the vendor or otherwise. Worst case, new customers of any system become unwitting development partners – library or otherwise!
Library systems in the enterprise
One interesting practicality is popping up related to bringing these systems into the enterprise (i.e. making full use of their interoperability, as well as ensuring that IT departments can provide the levels of technical support and business continuity that is an essential for a critical student-facing system.
As an entirely generic statement, IT functions won’t necessarily be openly welcoming, joining the party with an immediate desire to run with implementation.
OLE can be quite startling where there are any comfort zones built on traditional waterfall systems development.
Procurement and finance functions can trip over the same reality.
There is also a flavour of ‘not invented here’ as a risk – even where there are strong relationships between IT and library.
Bringing next gen into enterprise IT may be a bigger challenge than has been evidenced yet.
Wrapping up, if there is a theme for the next stages of Kuali adoption – and OSS more widely – it is finding a balance:
- between vendors and OSS providers/communities;
- procurement processes.
Whilst the event was another classic example of the sum being greater than the part, thanks go to Andrew Preater and Robert McDonald in particular who pulled the event together in style.
Senate House and University of London support for the event was also hugely welcome.