Oh, yes. The University of Tennessee at Chattanooga's library is implementing the OCLC Webscale Management System, and if all goes according to plan, we will have it up and running in 30 days.
You read that right. My library team is implementing a full-scale, whole-hog library system migration to a heretofore unknown system. We’re making The Big Jump. We’re going to live in the cloud (it’s okay, we promise to write). We are divorcing the traditional ILS, taking the kids, and striking out on our own.
We are stepping into the future. And we’re doing it in a grand total of... thirty days.
Our Library has been batting around an ILS migration for years. We looked at the various vendors and decided that while our current workflows would likely conform just fine to another traditional ILS, it wouldn’t really be changing anything. We’d just get something similar that actually, most of the time, hopefully, would work, and with (again, hopefully) better response to service calls. There were a number of other factors, cost and budget of course among them. We also debated the wisdom of falling further under OCLC thrall.
But there was also the consideration of what this opportunity might mean. A chance to be in on the ground floor of building the sort of library system everyone bitches that we want but don’t have. A way to challenge traditional ILS vendors to do something more than patching their 1980s software, to build something that takes advantage of new technologies, new ideas, and isn’t just a giant workaround-enabler.
I’ve heard the argument against it, about OCLC hegemony, and the danger to our local holdings, but I posit this: If our users can’t *find* our local holdings – which in the case of our soon-to-be-former OPAC they can’t - those records may as well belong to someone else anyway. In fact, they may as well not exist for all the good they do.
And essentially, that’s what it boiled down to, in the end, which is why I love working here. It was not “Is this the most shiny toy?” It was not a matter of “This will be easy” or “we will be first.” We did not ask “Does this sound like too much work?”, although we did consider whether we had the capacity to do the work required. Our first consideration, the specter at the table at every meeting, and our last consideration was: “Will this move be the best way to serve our user community?” And because the answer was yes, we took the leap.
The leap was assisted by the fact that during the demo of WebScale, I kept breathing, “Ooh, that is sexy.” About a web interface. About a web interface intended to run a library. When was the last time your poor old ILS helped you out with your work so well, or got dressed up enough for you to call it sexy?
Yeah, us too. And so, we’ve told poor old ILS that we’re leaving, and we’re taking the kids.
[Sidenote: I will add that the fact that our decisionmaking in this library is primarily driven by the question above - “Will this move be the best way to serve our user community?” - is also the very reason I choose to work here. It’s not the party line – it’s practice.]
Oh yes, we’re crazy. Our IT team is crazy to take this on, but Head of IT Jason Griffey and ILS administrator Andrea Schurr are just badass enough to make it work, and are already hard at work wrangling data. Our Head of Materials Processing, Mike Bell, is crazy for taking on the massive amount of records work that needs to be done by his department. I’m crazy for throwing Access Services into a system that’s not quite fully built and demanding that we provide excellent service while the Library monkeys with it and help OCLC design what we think a working library system looks like. All of us are going to be (if we’re not already) insanely busy, breaking down all our processes, figuring out how existing workflows will be impacted, and working in tight, small implementation groups to ensure that the only impact our users feel is a positive one and that our change is an agile one.
And we know we’ll be impacted in ways we probably can’t predict right now. I’m not a technical services person, but from what I *do* know of technical services, OCLC’s WebScale seems to be a massive sea change in the time, number of steps, and ease of doing tech services business, and I expect that this – as well as a number of other new ways of looking at library systems as a whole – will allow us to evolve as we were meant to, without being shackled to software we pay a mint for and have very little input into making changes in. Our needs are not the same as they were fifteen years ago, nor are our collections, our technological capabilities, or our staff’s skill-sets. So why are we married to software that works the same way it did that long ago?
Because we haven’t had a choice. And while we’re still a number of weeks away from full implementation, the energy in the library is palpable. We aren’t just hoping this works, we are DEMANDING that this works. We are refusing to accept the old library and ILS excuse of “but this is the way we’ve always done it,” and are working hard to chart this new path. I hope it goes somewhere pleasant.
I think this is an exciting time to be looking at how we run our libraries, in light of OCLC attempting to develop the product libraries have been asking for, and as we wait to see what will come of the Open Library Environment (OLE) product over the next few years. Expect to see much more about this project here, as well as at Griffey's blog in the coming weeks as we kick the tires, find gaps, and test OCLC's commitment to service (as well as our own mettle).
You can read more about Webscale in Andrew Pace's archive of web-scale category posts, some discussion on OCLC's page on web-scale here, and at OCLC's official Webscale Management System page.