Service Oriented Library Systems Pt. 3: Where Are We Heading?

This is the third (1 2) in a series of posts discussing Service Oriented Architecture (SOA) and library systems. In my second SOA post, I discussed how library systems in this environment are structured in information silos and the impact this has on the user experience.

SOA is essentially a modular software design philosophy which facilitates the flexibility and responsiveness required in a changing environment. Individual software pieces are build independently and can either be interchanged or repurposed. SOA utilizes 'loosely coupled' systems that expose their resources and content as independent 'services.' These services can be combined to create new systems and services. The most visible result of the SOA approach is the emergence of web mashups.

The best analogy I have found to get a handle on SOA is the early twentieth century automobile assembly line. It is also important that the concept of web services which is tioed to the concept of SOA not be confused with services available on the web. Web services in this context refer to a specific type of application built on an architecture that offers the promise of allowing any client to work with any server, anywhere in the world.

The graphic below depicts how just one library system, the ILS, could look like using the SOA approach. In this example, the bibliographic database, circulation, and authentication systems have been decoupled from the discovery tool and presentation layer (customer interface).

Each of the services (circulation, authentication) or the presentation layer could be replaced or updated with minimal impact on the overall system/service. For example, a library could create a social web interface to the ILS without touching the bibliographic, circulation, and authentication services. An SOA ILS would not have to rely upon a built-in circulation service, but could 'plug in' one from a commercial vendor or one that is built locally. The data collected could would not be embedded like a 'silo' ILS and could be maintained over generations regardless of the changes made to the other ILS modules.

Another advantage to the SOA approach is control over the bibliographic data. It is common for ILS vendors to 'lock' the bibliographic data into the 'silo' ILS using proprietary data systems and formats. The costs associated with the export and conversion of this data may be the single most significant reason libraries rarely switch ILS systems. With SOA, the local bibliographic database can be replaced by a web service. (This currently fictional web service could serve as the foundation for the next generation SOA ILS. Hint, hint, OCLC). The use of a bibliographic web service would not only remove the retro-conversion barrier, it eliminates the need to maintain a local bibliographic database all together!

Before the catalogers out there react to the previous paragraph, if the library wanted to create a localized database for special collections or supplemental information they could do so. They could create a database using common tools, expose it as a web service, and simply 'plug it in.' This new web service could be shared with consortia wishing to aggregate special collections resources or it can be 'mashed' together with other web services.

In my second posting, I discussed all of the various systems that our customers must navigate. The graphic below depicts the beauty, and complexity, of this approach.

With such a design, all the systems would be loosely coupled. Direct connections to each of our data sources would be available from any of our our web presences. The user experience is enhanced since they could gain access to any of the resources from any of the user interfaces. For example, one could search the course management system and receive results from the eJournals collection.

The graphic above also assumes that libraries would continue to need separate user interface sites. In theory, with SOA the library could create a single Facebook-like portal which would aggregate all networked resources. New library 'web services' could be built and simply plugged in by the customer.

This approach to the design of library systems represents a radical departure from what we have today. At the same time, it provides libraries with an unprecedented ability to create and maintain systems that can quickly adapt to the changing networked information infrastructure. It has the potential to get our resources out to where our customers are.

In part four, I will discuss the challenges with moving towards a service oriented approach to library systems.

CONTENTS:

Part One: Introduction
Part Two: What We Have Today
Part Four: Challenges
Part Five: Final Comments Sphere: Related Content