future directions of library systems

It was great to talk with various enterprise/IT/technology architects at DLF Fall Forum 2007 about our various ideas an approaches to modeling and implementing the new library technology infrastructure.  But it's clear there are still more library technology architects out there (even if they may not have that in their job title), I ran across an interesting blog posting by Jonathan Rochkind:

Notes on future directions of Library Systems from Bibliographic Wilderness blog, September 28, 2007

Here are some notes on near/medium future directions of the library systems environment/architecture, and a sketch of requirements on where we want to go. These notes may or may not end up as part of an internal white paper here, as we analyze where we want to be headed (something good to do anyway, but we got a kick in the pants when the vendor ended development on our current ILS).

...

The library systems environment has grown from being composed of a single “Integrated Library System” at the origin of library systems in the 1980s, to being composed of an ‘ecology’ of systems in most libraries today. These different systems could be from various sources (proprietary and open source), fulfill various–both overlapping and distinct–functions, are used in various ways by different subsets of users (both library staff and our end-users), and interact with each other to varying degrees (some well, some poorly). 

I wonder if I should consider adding a "library technology architecture" category to SLP?

PS Jonathan was at DLF but we didn't formally meet, it's odd how sometimes virtual connection and discovery is easier than in the physical world.

Comments

[Jonathan Rochkind]

Hi Richard, sorry we missed each other at DLF. I DID in fact keep seeing you around, including that one elevator ride at the end, but I was just so burned out on meeting new people and making conversation by that point, you know? Next time let's make a it a point to meet for real.

[art]

I guess the challenge might be to define metrics of impedance, throughput and fidelity. Ask almost any undergraduate what they like about google, and one of the responses will be that it's freakin' fast. An API that is layered too far upstream might deliver high fidelity content or functionality, but introduce too much latency to the process.