A Long Look @ Service Oriented Library Systems

In my three (1 2 3) SOLS posts I have provided a basic introduction to SOA and how it can be applied to the development of the next generation of library systems.

Historically, library information systems solutions have been built (almost) exclusively by vendors. While some libraries do build their own systems or use open source solutions, the large majority still rely upon vendors. Most of our challenges in implementing SOA are the direct result of this decision.

Commercial software developers rarely develop new products until they find a critical mass of users since they need to recoup development costs and make a profit at the same time in order to survive. The relatively limited size of the library system market makes it a difficult one for new vendors to enter. This means libraries have few choices when choosing software solutions and few libraries will switch once a significant investment in licensing, maintaining, and training support. When a library becomes so dependent on a vendor for products and services and cannot move to another vendor without substantial costs, whether real or perceived.

The first challenge to adopting SOA is that library systems vendors have created an effective paradigm that many libraries cannot afford to break away from. The vendors of key library systems understand the lock in phenomenon and libraries let them get away with it.

Many library vendors, if not most, build their solutions upon proprietary architectures. Some vendors are beginning to build their systems around some of the principles of SOA. Still, the core of what makes SOA work - the API - remains one of their their most tightly guarded core intellectual properties and revenue streams. The vendors place a death grip on those very APIs which would allow libraries to create SOLS using services provided by disparate systems.

The lack of compatibility between different library systems intentionally or unintentionally forces a customer to continue to use products and services from a particular vendor. Developers may design their products so that replacement parts or add-on enhancements must be purchased from the same manufacturer, rather than from a third party. Developers may also build in incompatibility between versions of their systems to force customers to upgrade.

The second challenge to adopting SOA is that the lack of compatibility and the API licensing fees charged to developers to create compatible products - required in SOA - creates a barrier for new vendors trying to enter the market for a particular library system. If the costs of entry or compatibility are great enough an effective monopoly can be maintained.

Libraries have built entire resource sharing networks around single vendor solutions. This results in a de facto standards. De facto library system standards are those which have been accepted for practical purposes by a significant proportion of the marketplace. What comes to mind is a significant library Internet document delivery network based on a product who's name is now a verb.

The third challenge to adopting SOA is that for work flow or legacy reasons we continue to support single vendor supplier solutions. In doing so, we create an environment where library products do not have to keep up with current technology needs, service support that does not meet expectations, and systems that will not allow for the adoption of SOA.

When one steps back and looks at it, we have nobody to blame for outdated library information systems or our inability to more readily adopt SOA except for ourselves. We keep licensing these products at a time when the number alternative approaches available to libraries has never been greater.

In the last posting in these services (no. 5) I will provide some closing remarks and observations.

CONTENTS:

Part One: Introduction

Part Two: What We Have Today

Part Three: Where Are We Heading?