ILS Customer Bill-of-Rights
We need to open up discussions with the professionals at our ILS vendors, database providers, and subscription services and ask them: “Are you making the best product you can that will work for all of my users no matter where they are?” Inquire about built-in RSS feeds, tagging, and user commenting while you’re at it. The vendors that get it are, hopefully, already communicating future innovations as these.
That’s sage advice, these are the companies that literally determine what we can and cannot do with our systems. ILS vendors, however are a bit of a special case.
There is a lot of talk about what Library 2.0 is, what Web 2.0 means to us, and what technologies can benefit us (RSS, tagging, etc). Fine. ILS vendors are going to see this as a potential gold rush and try to capitalize on it at, what I fear, is our expense. And we may quite possibly be enabling them.
Why do I say this? Well, first, let’s look at what’s at stake here. Essentially it’s our data: our catalogs, our patrons, our website content, our library programming, etc. This is our precious gold. This is the raw material that we will use to shape the future of library services. The traditional business model that ILS vendors have pursued (and forced on us) does not give us the freedom to use our own data in the way that we’re ultimately going to want to use it.
That’s where the problem arises. If we put pressure on ILS vendors to begin providing new Web 2.0 type services, they most certainly will. They’ll charge for it, you’ll pay it and finally have RSS feeds, blogging functionality, whatever. Excuse me, but that’s crap.
Let me use RSS as an example. RSS 1.0 was born December 2000. RSS 2.0 in September 2002. It’s almost 2006 and ILS vendors are just now starting to unveil some RSS feeds. We shouldn’t be treating those announcements like watershed moments. They’re tidbits of “too-little-too-late” packaged in shiny wrappers, served with a helping of “Who’s your Daddy?”
No, that’s not ok. It’s certainly not innovative. We need another model that will allow us to handle progress ourselves because we can not, must not, rely on our vendors. So what should we be asking them for? In the face of Web 2.0 advancements, what is something concrete to demand of vendors that will enable us to implement our own individual visions of Library 2.0 and prepare us for what comes after?
I envision a library Bill-of-Rights with four simple, but fundamental must-have’s from your ILS.
1) Open, read-only, direct access to the database.
When I say “open” I mean, we should be able to run any query at all against our own data, however absurd it may be. “read-only” because I understand the need to protect data integrity, but no harm can come, whatsoever, from getting your own data out. Many vendors offer this already. Good for them. It should be standard. It should also not be prohibitively expensive. III, for example, provides the option of using an Oracle database in place of their own proprietary one. Going with Oracle would give you the ability to do SELECT statements, but who can really afford it? Especially after shelling out your next two branches for III itself. For most libraries, an open-source RDBM like MySQL or Postgres would not only suffice, but would be ideal.
2) A full-blown, W3C standards-based API to all read-write functions
This is the big one, because all else stems from here. We ought to be able to access every level of functionality inside our automation system using an open standards API. Everything from modifying a patron’s home address to cataloguing new items should be included. I envision a vast set of functions that can be described via a standard WSDL stream for interfacing via web-services. In addition, shared libraries need to be made available along with proper documentation. Ideally, these would be the same libraries and APIs that vendors themselves use. It’s clean, simple, and it makes so much sense. (It’s also why I’ve said before that vendors need to rewrite their software from the ground up)
Given these tools, libraries would be empowered to roll out new services and features in their time-frame, not that of the vendor. Vendors could still (and should still) provide templates for the more popular features such as RSS, but we wouldn’t be reliant on them. It would also let vendors focus on what they really should be focused on: the quality of the automation system itself. This isn’t a take-us-through-the-next-3-years feature. This, alone, is a major evolutionary necessity for the survival of the online library. If we don’t get this, we will fall irrepairably behind the curve.
3) The option to run the ILS on hardware of our choosing, on servers that we administer
We should have access to the machines that run our ILS. This does two things.
First, it ensures that we’re not being taken advantage of. If vendors know that we can log in and install better alternatives to the software and hardware they are reselling us (I’m thinking backup software in particular), they might be less apt to screw us with our pants on.
Second, it gives us the flexibility to run software locally doing tasks that we might not otherwise be able to do, such as cron jobs that parse logs, data files, etc.
As it stands now, if I know security is a problem on the machines running our automation system, there is very little I can do about it. We need to have the option of administering our own servers and being as anal about security as we like. This is about flexibility and accountability.
4) High security standards
I’ve made no secret of the fact that I think library infosec is unacceptable. Vendors need to step up now, review their best practices, and implement some very radical changes to the way they’re handling everything from roll-outs to patches to access protocols. We have the right to peace-of-mind (and so do our patrons, for that matter).
Looking at this list of four fundamentals, I’m thinking, “this is as basic as it gets.” This is not shoot-for-the-moon stuff. Yet, if conceded these features, we’d be given all the tools we need to permanently change the way we adapt to emerging trends.
About this entry
You’re currently reading “ILS Customer Bill-of-Rights,” an entry on blyberg.net
- 11.20.05 / 11pm