A way I’ve been verbalizing something we all think about lately:
Our ILSs were originally intended to support our work flow. The old-fashioned-sounding phrase we still use–“automation”–points at this. We were providing ‘automation’ to make individual jobs easier. Whether the ILSs we have do this well or not is another question, but some still assume that the evaluation of an ILS stop and ends here.
But in fact, in the current environment there is another factor to evaluate. Not just work flow support, but ILS serving as a data store for the ‘business’ of the library. The work that the ILS is supporting produces all sorts of data—the most obvious ones being bib records and holdings information, but it doesn’t stop there. The ILS needs to provide this data, not just to support current identified work flow and user tasks, but to be a data store in and of itself for other software, existing and yet to be invented, supporting tasks existing and yet to be discovered. The ILS needs to function as a data store for the ‘single business’ of our library. Not neccesarily the only one (although there’s something to be said for a single data store for our ‘single business’), but the data that IS in there needs to be accesible.
Thanks to Lorcan Dempsey for pointing out the concept of ‘single business systems environment’ in the National Library of Australia’s IT Architecture report, which got me articulating in this way. I think it’s on the way to a useful way to articulate things which are often understood by ‘us’ but not articulated well to ‘them’ (adminstrators, vendors, our less technically minded colleagues).
Bibliographic Wilderness 