Richard Wallis has posted a very thoughtful and reasoned response to my ILS customer Bill-of-Rights. I was really excited to see that people at Talis are taking this discourse seriously, and I’m thrilled to be having this conversation with them. In lieu of their recent whitepaper and their willingness to engage in this discussion at all, they seem to be among the most progressive of the lot and I’m guessing we’ll see some very promising things from them.

I wanted to address some of the comments that Richard made, however, since I still stand by all four of my original recommendations.

Regarding “open, read-only, direct access to the database”, Richard writes:

This first one I have difficulty with. An ILS is a complex beast, and because of performance tuning and inevitable data denormalization its database is even more so. Open access to the database, especially if it is the one servicing the live ILS can be dangerous.

I can’t think of a case in which running SELECT statements against a RDBMS would be dangerous under any conditions. (more on ‘why’ below)

As a vendor, here at Talis, it is not unknown to be contacted by an unhappy customer complaining about OPAC performance only to discover more than one heavy-weight MIS process being run against their database at 11:00am on a weekday

Perhaps, a series of simultaneous, poorly written queries could slow the system. Setting aside my personal opinion that we should be able to make that decision for ourselves, a system slow-down is not a dangerous situation. Any mission-critical data modification that may be going on is being conducted with transactions which can be rolled back given the absolute worse-case-scenario. If you’ve designed your software to recover from a catastrophic power failure, surely it can handle a pegged CPU or extremely heavy loads. In any event, I don’t think this situation would be common, especially given the type of server hardware we now see being deployed with new systems. This would’ve been a much more valid argument were he referring to our old DRA Classic running on a DEC Alpha.

I would rephrase this must-have to read Open, read-only access to the data in meaningful form utilizing Web Service techniques (see must-have 2) an ILS should be able to deliver what you would ever want/need whilst utilizing the business logic of the ILS therefore ensuring performance and a ‘true’ view of the data. Raw SQL access to data very often does not take in to account subtleties of business logic that have evolved [in code] over years of development and return wrong results.

Well, the problem with this, is that it assumes that the vendor will provide methodology within their web services inventory to do absolutely everything the customer wants. I’d maintain that there is no way for a vendor to anticipate every need of every customer. The reason my first “right” is so important, is because it’ll force vendors to acknowledge this fact, and adopt a new way of thinking about their customers. It ensures a state of ‘absolute availability’, which is the end goal here. The idea is to completely change the way the vendor-client relationship works and how either side regards the other.

Duplicate databases can help, but these then introduce synchronization issues, and still leave the problem of understanding what the data in the tables actually means.

This doesn’t give enough credit to those of us who hack away on these systems every day. We’ll figure it out. Bear in mind that open access would not be a feature for the average system’s specialist. It would fall in the domain of the coders and hackers (”hackers” in the traditional sense). This is also exactly why I stated “read-only” access. I completely agree that any data modification whatsoever needs to be handled by the business logic via API. My guess is that it would actually benefit the vendor to have a customer base who is familiar with the database schema. Imagine the type of feedback you might get from that person!

I think the real issue here may be a vendor’s ability to ensure that their intellectual property is not compromised. Database schema, or design falls into that realm. I can understand that vendors don’t want their competition to know what they’re up to. As such, I believe that it would be perfectly acceptable to sign a non-disclosure agreement (most libraries do that now anyway, right?) that stipulates that a customer will not distribute any source code that accesses the database with this method. Vendors are companies, and we need to respect their ability to do business.

Regarding server platforms, Richard writes:

This brings me back to that old chestnut of supportability. Even in this ’standard world’ that we operate in in the 21st century, complex software packages do behave differently on different kit, the more variations the bigger the problem. Nevertheless this is a great goal to strive towards.

This is a great point and being a network administrator, I can fully sympathize with the issue of support. Let me be clarify my statement, “[we should have the] option to run the ILS on hardware of our choosing, on servers that we administer.” First, the idea of ownership and control should be fostered with the customer. It’s very invasive for a vendor to assume that they can just outsource the deployment of hardware in a library’s data center without being familiar at all with that library’s infrastructure. That should be an option. It’s completely reasonable, on the other hand, for a vendor to provide the client with a very specific range of hardware and operating system requirements and let the customer do the install. Yes, it could potentially be a support burden, but then the customer should pay for that support. My guess is that most libraries would opt for the outsource.

Personally I am hoping that eventually we will be able to run an ILS appliance (a bit like the Google appliance) where you don’t know, or care, what OS or database is under the hood.

I rarely recommend the purchase of an appliance in our enterprise because they tend to be locked into a very narrow and rigid functional spectrum. This idea interests me, but I’m skeptical.

Richard didn’t directly address my assertion that we should have administrative control over the servers. Look, if we hose the box, we’d be responsible for the cost of bringing it back online. I find it very improbable, though, that a customer would do anything to jeopardize the server their ILS runs on, but having the control and freedom to administer the box gives you the freedom and flexibility to run local processes that might be essential for feature X. It also allows you to install your own mission-critical software like backup and recovery agents.

It’s good to hear someone in the industry talk this kind of talk, and I’m looking forward to see what shakes loose. Thanks for the great reply Richard. It looks like Talis is listening!