Disruptive Library Technology Jester Peter Murray follows up on his earlier post, which Richard blogged about yesterday. In “The Dis-integration of the ILS into a SOA Environment”, Peter begins to address the vexed question of;
“what to do about the Monolithic (er… ‘Integrated’) Library System.”
A good question, indeed, and one that you don’t need a floppy hat with bells or a marotte to ask. Go on. Ask your vendor if they have plans to do more than just slap a ‘Library 2.0’ badge on their next release and give its interface some curvy corners.
There is certainly scope to break today’s library systems down into their constituent parts, providing APIs and other mechanisms to enable effective communication between the pieces. As Peter suggests, a significant number of the functions currently bundled inside an LMS/ILS aren’t actually very ‘library’ at all. Might SOA enable libraries and their systems to concentrate on the tasks that are distinctive, calling upon finance, stock procurement and similar functions from equally SOA-friendly systems elsewhere in the institution? How many times, for example, does an organisation like a university specify, procure, pay for and maintain a capability to capture the home address of a student? Far too many, I’ll bet!
As well as enabling vendors and their customers to give serious thought to tightening the scope of ILS/LMS functionality, a Service Oriented approach also raises the prospect of exposing information from inside the library system in interesting new ways that directly address users and their needs. Yesterday’s announcement of an Open Source toolkit for Talis Keystone illustrates some of our moves in that direction, and there is of course far more to come on that front. There is even a sandbox in which you can develop and test your own Keystone-enabled applications. Technology like Talis Keystone does two things; it enables the existing ILS/LMS to play a fuller role in the information ecosystem within your institution; and it begins to offer more of the components with which we could all apply our attention to building a very different solution to library system construction, encompassing all of the library’s physical and electronic resource type needs, whilst passing the more generic processes off to appropriately empowered services in other parts of the wider organisation.
Lorcan’s response to Peter’s “Services in a Service Oriented Architecture” post is also interesting on several levels. To extract one comment to which there is an easy response for someone preparing himself to leave the office for another week and endure the weekly cross-country encounter with the evening traffic clogging the UK’s motorway network;
“Some of the services that would be required in this service oriented framework would be part of what I have called the ILS Service layer, programmatic ways of accessing the functionality of the ILS. So, for example, the ability of Worldcat.org (or some other application) to ‘reflect’ the status of an item in a library, or to place a hold on it, would depend on such a service layer.”
I couldn’t agree more. Programmatic access to capabilities and potentials, offered in a way that removes the aggregator’s need to concern themselves with the flavour and version of your ILS/LMS? Programmatic access that means the user need only interact with a library user interface if they want to? Programmatic access that means software can pull this stuff together and act upon it on our behalf? Bring it on! Which, of course, we are… Platform APIs. Talis Keystone integration pieces. Large, scalable and affordable stores of data, freely contributed, freely shared and freely consumed by the wider community. Watch this space for the next piece in a puzzle that looks more fascinating every day.