ORIGINALLY PUBLISHED on March 3, 2016 at http://blogs.brandeis.edu/libsys/2016/03/03/whither-modularity/
I do not consider myself a visionary.
I’ve watched plenty of ideas excite the library tech community, and thought “hm, that’s interesting.” But I’m a concrete person. It’s when an idea starts demonstrating practical applications that I start to get excited. E.g. I was aggressively ambivalent about linked data until I started learning about Bibframe – a practical application in my lib tech niche, and an exciting development for future advances in metadata management and especially discovery.
If you’d asked me in 2007 what I thought would happen in the ILS world (and my University Librarian did ask me) I would have said (and I did say) that modularity would finally win the day. We were about to enter an era where we could
- choose our metadata database
- choose our tools for how to add, edit, manipulate your data
- choose our inventory management/circ tools
- choose our discovery service to expose our resources to the public
and none of that needed to be from the same vendor. It just needed the right integration tools. APIs were a little on my radar in 2007 but I was really picturing buying different modules from different vendors expecting they’d have figured out how to plug & play.
Well, then ExLibris announced Alma, which at the time was called URM, and I was very disappointed, both in the direction of ILSes and my own powers of prognostication. Especially when other vendors started falling into line with their giant “re-integrated” systems – Sierra, InTota, WMS – all of which seem to be called Library Services Platforms (LSP).
We’ve headed back in the direction of brobdingnagian one-stop-shopping library management systems. Granted, they are ostensibly now fully integrated resource management systems for both print and e-resources, with the attendant acquisitions, inventory, etc, but their big transformative value-add is really just that we can now manage e and p in the same interface. The Library Services Platform as executed by ExLibris & OCLC is at its heart an ILS.
————— (awkward segue to the paper which sparked this post) —————
I recently read a paper from Ken Chad – Rethinking The Library Services Platform* – which sparked my above statement about today’s LSPs being essentially ILSes. The paper has me thinking seriously again about the type of modularity I wanted in 2007 and still want. I’m not here to summarize much of what he writes; this post is just my thoughts & reaction to the paper. You should read it!
Bottom line: the paper feels like a call to action. We need to transition to LSPs that are centered not around managing our store of marc records (maybe someday bibframe?) but around how our community needs to interact us. “[L]ibraries are a means to an end and success ought to be measured in terms of the best possible customer experience and outcomes” (Chad 2016, 5) From the user perspective the library is the front end of all the systems we take care of – it’s the metadata (and objects) we present to them. And as much effort as we put into creating and curating metadata for them, I’d wager that the majority of the metadata they use is not ours and it’s not in our ILS or in our repository – it’s at EBSCO, it’s at ProQuest, it’s at JSTOR. And a lot of the metadata we create we also contribute to OCLC. So why is the ILS the centerpiece of how we serve our users?
Big dream moment: What if LSPs existed that were open to 3rd parties developing apps that plug in, and used standards effectively so that apps were portable between LSPs? What if we had true modularity with the tools we use to manage our data and – most importantly – address our users’ needs?
ExLibris has made an apparent commitment to “openness” with Alma – the developers network is open to the public, API documentation is open to the public. They are making noises about not being closed, about encouraging third parties to develop things that will interoperate with Alma and Primo.
If this kind of openness is real, and they don’t close things off either intentionally or through oversight, it offers the opportunity to develop some of the tools we want to use, that are better tailored to our local idiosyncratic workflows.
Even bigger dream moment: My dream is the equivalent of an app store where we can buy the circ module we really want. Or what if we were one of the third parties authoring the tools we and other libraries want? What if we could build our own request tool that didn’t require the user to know where they needed to ask for something – ILL vs a hold in the ILS vs scan-on-demand document delivery? What might we be able to author for ourselves given the right platform to build on?
Ken Chad talks about “interoperable applications from independent software vendors (ISVs)” Each of us, given the time and the inclination, could be one of those ISVs.
The open, interoperability-ready Library Services Platform we’d need to author our own tools or select from third-party add-ons doesn’t really exist. But in the meantime, we could encourage the trend by using and/or creating tools that take advantage of the purported openness in the existing services like Alma, Primo & EDS. We can test the vendors on whether they really mean to be and stay open, and somehow incentivize them to allow the type of modularity I wished for years ago.
*Rethinking the library services platform. By Ken Chad. Higher Education Library Technology (HELibTech) Briefing Paper (No.2) . January 2016 . DOI: 10.13140/RG.2.1.5154.8248