Service Oriented Library Systems Pt. 2: What We Have Today

In this second post on SOA, I will focus on how computer applications have been traditionally built using library examples. What I will present may be an overly simplistic explanation of system design. The intent for this series of posts is to provide a basic conceptual model which less technical oriented librarians can understand, not for those with CIS degrees.

Most of our current (and legacy) library systems take on the structure depicted by the graphic below:

Each of the systems that libraries use are self-contained silos. Each has its own embedded database/data structure, built-in search tool, and presentation / interface layers. Each requires library customers to use its unique presentation and search tools to access its unique content. Each has a completely different look, feel, and functionality.

From the user experience perspective, this system design strategy is why it is so difficult for librarians, let alone library customers, to find Time. It is also why many libraries have spent a great deal of resources creating extensive educational programs to teach how each of our systems work.

(This would be the point in the conversation that I would normally discuss federated search. I would talk about how it is in many ways a patchwork solution to get around the silo structure of our information systems. But that is a discussion thread for another time.)

The silo structure (or, as I also like to refer to it: monolithic structure) is also one reason why we have difficulty in getting our services integrated. For example, this structure almost requires libraries to purchase interlibrary loan management systems with integrated Internet document delivery tools. What if we do not like the built-in Internet document delivery tool? We are either stuck using a system we do not like or run two, three, even four different systems and build work flows around them!

Lastly, the data/content we create becomes fixed within each silo. The costs in real dollars and staff time, required to export, convert, and import are some times so significant that we hang onto our systems and rarely change. This results in a phenomenon called 'lock-in' which vendors are not only aware of - they build business models around it! It creates an effective library systems paradigm which libraries have not been able to break away from.

It doesn't have to be this way.

In part three, I will discuss how service oriented architecture (SOA) can improve resource aggregation and the user experience.


Contents

Part One: Introduction

Part Three: Where Are We Heading?
Part Four: Challenges
Part Five: Final Comments Sphere: Related Content