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

Service-Oriented Library Systems Pt.1: Introduction

This is the first of a short series of posts that will discuss Service-Oriented Architecture (SOA) and libraries.

I am certainly not alone discussing SOA. Marshall Breeding is one of several that have been discussing SOA approach as has OhioLinks' Peter Murray and CISTI's Richard Akerman (NOTE: The July 15th issue of LJ will have an article by Richard on SOA). It is a concept that librarians need to be exposed to as often as possible.

SOA is a systems design architecture approach / philosophy that has been around for a while, but one that has come of age. It is also a difficult concept to explain to non-developers and those without a techology orientation. The documentation for SOA is pretty thick and geared towards CIS professionals. That is why I have found the analogy of changes in the early twentieth century automobile assembly line communicates the general concept. The most visible result of the SOA approach is the emergence of web mashups.

The move towards SOA for library systems has the potential to improve the ROI by providing a better access to and aggregation of the information resources we license. For example, with SOA consortia libraries could work together to build systems sharing common bibliographic / resource data and then build customer interfaces and search systems which look and work quite differently. SOA can allow libraries to use and improve information resources contributed by others and customize its delivery to customers.

The adoption of the SOA models can enable libraries to evolve into stronger organizations at the very moment in time that the use of libraries is becoming just another piece of the customer’s information seeking experience. All librarians, especially library leaders, need to understand SOA.

UPCOMING:

CONTENTS:
Part Two: What We Have Today
Part Three: Where Are We Heading?
Part Four: Challenges
Part Five: Final Comments Sphere: Related Content

Create Your Own Mashup

Last week at the Library 2.0 Seminar I was asked about Yahoo Pipes. I had heard about Pipes but hadn't played around with it to know how it worked. Yahoo Pipes allows individuals to create their own mashups or "pipes." The process involves dragging and dropping prebuilt modules, and then create connections between them.

The Pipes method of building mashups does require some time to learn. (I spent 15 minutes, which admittedly is not a great deal of time. Yet, that would seem to be a reasonable threshold if they want the 'average' person to use it to create mashups) They use terminology and structure that is used may turn away many potential mashers that have a non-technical orientation. I had hoped to use Pipes has a tool to teach librarians about SOA and Web Services. It is going to take some time to figure out if it can be used for teaching.

The number of sources from which to build mashups is limited at this time which limits creating mashups relevant to libraries. The also seems to take quite a while for the tool to load the sample Pipes. I learned HTML by tearing apart other people's code and hope I can learn Pipes using a similar method.

Microsoft's Popfly is another plug-and-play mashup tool. Like with Pipes, one can drag prefab building blocks. mashup that you can add to an existing Web page or turn into its own site. For example, one can produce a mashup that grabs pictures from a site like Flickr and then displays them in a rotating cube. As with a growing number of new tools, PopFly is invitation based and requires a WindowsLive ID.

Photo: "The Pipes, The Pipes" by Steve Garfield. Published through Creative Commons license. Sphere: Related Content

CIC / Google Cooperative Agreement Details

For those of you that find reading legal documents enjoyable, the 16-page Cooperative Agreement between the CIC and Google has been posted on the CIC web site. Sphere: Related Content