shared ILS concept

The Orbis Cascade Alliance's Collaborative Tech Services Team has been charged with implementing "a Shared Best Practices working group to develop guidelines for effective technical services policies and operations that support the Alliance goal of a shared ILS (Integrated Library System)."

At our team's first meeting, I was charged with taking a shot at what an ideal Alliance shared ILS might look like. I am supposed to produce a white paper on this topic for consideration by the Team.

The work of the Shared Bibliographic Database Task Force serves as a good starting point in this thinking process. Their report points out many of the potential implications of a shared ILS as well as advantages and drawbacks (scenario 3).

Perhaps the most common notion of a shared ILS would be all 36 Alliance members piling on board a traditional ILS software package that was designed for large, complex organizations (but might not be designed to handle as many separate and large organizations and sub organizations as comprise the Alliance). A big advantage in doing this would be savings on system maintenance, local system administration and hardware costs.

To make this happen successfully, member libraries would have to standardize their operations around certain system settings like circulation loan rules because the system simply couldn't handle as much local variation as is in place now. This standardization might create efficiencies in itself in that it would promote common best-practices workflows around the shared settings. A shared system could also create efficiencies through the reuse and sharing of data. For example, by sharing bibliographic records, we could reduce the overall time and effort required for database maintenance.

The big disadvantage in sharing a system this way would be a potential lack of flexibility to tailor the system to the each institution's needs: whether this customization came in the form of special loan rules, distinct subject headings, etc. Another issue might be that the system would simply become unwieldy for staff to use because data from all the institutions would overload user interfaces for staff. Imagine having to wade through hundreds of item records for a given bibiliographic record (of course these effects could be mitigated by special views, etc.) And finally another disadvantage would be the potential red tape needed to make any change to system settings.

Another model of a "shared ILS" would provide every library with an independent "virtual" ILS delivered in a Software As a Service (SAAS) fashion. Because the software would be delivered over the web, we would "share" the underlying software and computing infrastructure. We'd be "sharing" an ILS with other Alliance members (and perhaps whomever else the vendor contracted with) but we wouldn't even know it. By doing things this way, we wouldn't lose any independence and we'd still potentially save money on system maintenance (both vendor supplied and via our own staff). But we wouldn't be gaining any potential benefits possible through the sharing of data.

The third option would be a hybrid of the two above and is the one that probably corresponds to the most likely reality. The ILS would be shared where there were benefits to be gained, separate where there were not. For example, in circulation every library could have their own patron types and loan rules, but those patron types and loan rules would map to higher consortial levels of abstraction in order to support borrowing between institutions (kind of like they do now in Navigator but in the same system). In acquisitions, data about what materials were on order at each institution would be shared, but fund data wouldn't. In cataloging, we would share bibliographic records but perhaps control some of our own fields. In e resources, both individual and group purchases and licenses would be supported.

Another twist, of course, is the notion of sharing the ILS on a global level, which is more or less the vision of OCLC webscale management services. This creates the need for an even higher level of abstraction than at that of the consortium.

In coming up with a model for an ideal shared ILS for the Alliance, I'll be considering all of these scenarios.