[These views are my own. Please comment with corrections!]
Drammen public library, to some public fanfare announced that they were outsourcing their IT needs to the Swedish Axiell Group. Seen by some as a brave decision, by others, myself included, as more of the same as this has basically been the case since library systems largely aggregated around a handful of system suppliers in Norway about thirty years ago.
Axiell Group has provided Quria, a cloud-based library services platform. For the sake of clarity, let me explain these terms:
- Cloud based: the software is on someone else’s computer
- Library services platform: software that lets you do library things
As a cloud-based system, it is assumed that there will be less IT involved in running the system. As a library services platform, it is assumed that the software will integrate all the traditional tasks that a library does with the ones modern libraries do (like events calendars, digital signage, etc.).
Of course, “cloud based” isn’t a useful term (indeed, I and other, more notable system engineers have taken to reading it as “banana”); I have worked on systems in Norway for more than a decade and it has been common for systems to be deployed in an equivalent way for at least the last five. How “cloud based” or not a system is is up to the marketing department; it’s typically the case that it’s more important for libraries that the installed system has a functional development-release pipeline, meaning that features that users need get pushed out constantly.
The term “library services platform” could have been a useful concept, meaning an API-driven, dis-integrated library system, but it has become synonymous with “what comes after “next-generation library systems”. Basically more of the same. In the case of Quria, I think perhaps this is an unfortunate thing, because I see signs after looking at Drammen’s installation that there are clues that the surface presented to end users covers a potentially interesting set of APIs.
Before I go on, I should add that I’m known for hatchet-jobs on library systems — I’m very rarely impressed. I am a system developer and I often find fault in systems. In library systems, I find a lot of faults. The reason for this is that I care about this domain and know quite a lot — not everything mind you — about the technologies behind library systems as well as modern web-based applications. There is often a mismatch between what I know to be best practice and what is implemented in library systems.
From a casual glance at Drammen public library’s site, I notice one thing straight away: it is a portal application, driven, as far as I can tell with the Java based Liferay, enterprise portlet server. (What is a portlet?) What does this mean? Well, Liferay is an open-source portlet server; open source is good. Portlets? Liferay received InfoWorld’s “Best Open Source Portal” award…in 2007. Liferay is a mature platform largely used in the corporate world (where I have implemented it) — and also in a few environments like NTNU (where I also worked with it). Liferay is a mature technology — it was Liferay 4.0 that won the award in 2007 — so mature, in fact that a senior colleague asked “do people really still use portlets?” It seems they do.
I have worked with Liferay quite a bit and have developed integrated portlets that follow the JSR-286 specification as well as had fun serving the same portlets to Sharepoint using WSRP. This being the case, what do I think about using Liferay in this way? I think it’s probably a good decision from a development perspective. From an end-user’s perspective, I’m conflicted.
The good things about Liferay include that it provides mature support for a lot of the tasks that we need to do in Web-based systems; things like authentication, users/roles etc. are supported and the whole portlet concept makes it easy to sew together content from different systems, although it does nothing to make it easier to integrate data from multiple sources into one whole. Liferay out-of-the-box supports responsive resizing and restructuring in a sensible way and Drammen’s site shows that this has been used with some success.
For the end user, Liferay without heavy customisation, will always feel like legacy web content. This is the case in Drammen, there’s a number of things in the feel of the application that really aren’t acceptable in a modern web application. In particular, request is a roundtrip to the server that reloads all the content.
From a technology point-of-view, Liferay isn’t a bad choice, it is a safe choice. It isn’t, however, directly compatible with the modern, quick-moving, lightweight approaches to web design that mean we can roll out a new interface with new interactions as-and-when we want. It is a monolithic product and there is a lot of configuration of this product, which experience tells me that roll-outs will be mostly be problematic. Using the un-configured, vanilla product isn’t really an option either given the fact that it is designed to be configured.
Looking at Drammen’s site, you can see how the portlet solution has been used, there are different information categories in different portlets, using probably standard options in Liferay to present calendared events, news, etc. This is fine.
The library catalogue appears from all the available data to be Axiell’s Arena product; this is a mature search system, which uses the Solr search engine. While the search is unremarkable, searching for library catalogue data suffers from all the usual issues because the data fed into the system is unfit-for-purpose in terms of the search engine (and here we can’t blame the engineers), while the workarounds to get the bad data to work are fun, if not effective. Arena uses simple a trick to get zero-results searches for kral marx to return hits for the correct spelling by turning on fuzzy search, which is fine, up to the point that one searches for benthic, which should return zero results.
It is a shame that Axiell isn’t more open about their product — they want you to sign up to get more information — otherwise I’d have liked to have looked at the possibilities of customising the data workflows and search configuration. I’m sure that the product could be made a lot better if work was put into these areas.
And there is the rub — I think perhaps libraries buying this kind of system imagine they’ll be saving money, but I suspect that they will spend as much time and money working around the system as they would have spent configuring and re-programming a more local system.
Working together with the library system vendor to make the search system better would have been an option, but I suspect that this isn’t covered by anyone’s strategy — least of all those purchasing the system. It would require a local product team and people who could write specifications that could be pushed over to the vendor…which I suspect isn’t part of the outsourcing plan.
So the verdict? Drammen effectively applies open source software in a package from Axiell. A win for open source. Quria is a fine example of how existing open source software can be deployed to provide traditional web presences in a way comparable with other traditional system suppliers.
With Quria, Axiell provides an innovative purchasing model for a traditional technological approach; this is directly comparable with the approaches from vendors like Ex Libris and soon, EBSCO.
Well done, folks!