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?
Part Five: Final Comments
Sphere: Related Content
Monday, July 16, 2007
Subscribe to:
Post Comments (Atom)
6 comments:
First and foremost, I dig this series you've been writing. Way cool.
I am a supervisory librarian at a PL and I sit on the board of our local resource sharing network.
We use SirsiDynix and the shortcomings of the system and company make me want to chew my own leg off.
Part of your thesis in part three is that librarians are partly to blame for the sometime disaster of their ILS.
Yet I'm hard pressed to see how. Perhaps massive collective action to move away from the Big Three to open source alternatives would kill the beast. But what is the average librarian on the street to do?
I can't change my ILS because we share resources and money with the other area libraries on the same system.
Further, we don't have the resources to migrate from a vendor ILS to an open source one.
I posit that we have been sold bad products and are too wedded to them to get out. But that's not our fault.
First off, Thanks for your comment and feedback, James!!
Hmmm...
So, I have this old car. I have to keep taking it in for repairs mainly since it was a bad product when I bought it. Sinking more money into it causes two problems.
First, by continuously putting money into the car I want to keep it even longer. I simply have too large of a fiscal and emotional investment in it to let it go - even though it is a piece of junk.
Secondly, by placing more and more fiscal resources into the junker I now have difficulty coming up with the cash flow required to put a payment on a new car.
I can complain how the car is a piece of junk all I want, but I am certainly responsible if I am so wedded to it that I decide to keep placing my limited resources into it.
There is one other impact my decision would have. Why would a manufacturer make their car any better if they have little competition and their buyers are content to put their money into the repairs?
Except I don't own the car nor do I have exclusive permission to fix, alter, or sell it as I see fit.
I believe that "why don't you just use Evergreen" is simplistic and ignores the heavy lifting and organization slogging required to extract ourselves from these systems.
All good points, James, and again thanks for being engaged in the discussion!
The car analogy wasn't intended to be a perfect fit for the situation. It was to focus on the cultural / behavioral cycle libraries are in when it comes to our information systems.
Since you brought it up, anyone that would license a "car" without exclusive permission to fix, alter, or sell it as one see fit would probably be seen as being, well, crazy. Yet, we do exactly that with our library systems?
Heavy lifting aside, alternatives like Evergreen and the move towards SOA are needed to break the cycle of dependence.
[Note: The British Columbia, Canada Public Libraries Service Branch (PLSB) proposed a 5-year phased implementation of the Evergreen ILS. PLSB estimates implementation of Evergreen across BC at just over $2 Million over 5 years, one fifth of the cost projected for market-based solutions.]
Often I feel these discussions leave out who is more responsible for making these changes.
Library directors and other "senior officers" are the ones who are in a position to get us away from these onerous ILSs. Rank and file deal with them but often have no power to effect a change.
Take me, for example. I am recently promoted to supervisor and have a seat on the board of our consortial committee. As someone who hates our ILS and worships at the altar of usability you can bet your sweet Texas ass I'm going to try to have our current system taken out and shot.
But it is incumbent on people in such positions to do this. Bosses and management have to cowboy up.
Post a Comment