@Richard — you correctly bring up the issue of the form of the question…it is a historical look at past integrations and not necessarily a statement of planned or future integration. We actually have a common phrase for that here in America — “Past Performance is No Guarantee of Future Results” — something that is included in any manner of financial service offering.

Your points about the industry in transition — of heavy-weight and light-weight integrations — are well articulated. That said, I also subscribe to Clayton Christensen’s theory that an organizations resources, processes and values make it very difficult for it to change direction. In this case, to move from heavy-weight to light-weight interfaces. Even if the soul of the company is willing, Christensen theorizes that the organization would have to stop listening to its best customers in order to achieve the shift. In such cases, Past Performance is really a Very Strong Indicator of Future Results.

Thank you to both of you for your comments.

The answers you picked out are symptomatic of an industry in transition. Transition from products without exception based on architectures that never envisioned light-weight loosely-coupled integration. Transition to a REST based service oriented architecture where integration between library and non-library applications should be simple and based on simple and open standards.

The “Do you have partnerships with other LMS/ERM vendors?” question in the survey demonstrates an attachment to traditional thinking towards integration. So far, with the traditional heavy-weight protocols we are used to in the library world, the only reliable way to get integration that works has been through a partnership between suppliers. Web 2.0 has demonstrated that with simple light-weight protocols, integration is possible without the need for commercial partnerships. There are many benefits that arise from partnerships, but they shouldn’t be a prerequisite for successful integration.

It is not all doom and gloom though. Initiatives such as the DLF’s ILS API defining simple REST base protocols that all vendors should be able to support, have started to gather momentum in the last few months. A momentum that appears to be supported both by vendors and open source groups.

Ah but will the vendors support such APIs? I hear you ask. For an insight in to the surprisingly open and forward thinking of at least three of the vendors, I recommend a listen to last month’s Library 2.0 Gang podcast (the position of the fourth even gets a mention).

The text was modified to update a link from //project.library.upenn.edu/confluence/display/ilsapi/Home to http://project.library.upenn.edu/confluence/display/ilsapi/Home on December 30th, 2010.

The text was modified to remove a link to http://librarygang.talis.com/2008/05/06/may-2008-ils-api/ on June 9th, 2011.

Our role in this relationship is to not look elsewhere for solutions – either in the community or with competitors – and remain with the One Vendor to Do it All. And let’s not forget to “re-purchase” your ILS every couple of years too, with the latest “special” upgrade ‘that’s not included with annual maintenance’ etc.

Some enterprising upstarts are challenging this, but I think most of the innovation and change will be catalyzed from the open source camps, where investments are just starting to rock ‘n roll..