Web services and open architecture: hype or reality?
In the current phase of library automation, we're inundated with the language of openness. Open source ILSs have promised to give libraries more control over their software than has been possible with proprietary products. Companies that produce and provide service for proprietary products have redoubled their efforts to offer more flexibility, openness, and interoperability through web services and other application programming interfaces (APIs), which allow applications to share and repurpose data. A new front has developed in the competition among library automation alternative vendors, who are racing to open up software and allow libraries more access to their data and internal functionality.
This new emphasis on openness can be a great benefit to libraries to the extent that it actually offers new capabilities otherwise not available. Still, it's often difficult to distinguish products that fully embrace openness from those where the claims don't quite match reality.
The ILS represents one of the largest technology- related investments that a library makes. Each library brings a unique set of expectations and requirements to the table as it implements its ILS. Through a careful selection process, the library will identify the system best suited to its fundamental requirements, yet no prepackaged automation system will completely satisfy all of the nuanced needs of every library. Equipped with an API, libraries with their own programmers have the option of creating functionality that fills in the gaps between the system as delivered and their specialized requirements.
The December 2009 issue of Library Technology Reports explores this issue from the perspective of both vendors and librarians through an extensive sur- vey. Vendors such as ExLibris,The Library Corpora- tion, Innovative Interfaces, Polaris, SirsiDynix, Talis, and VTLS were asked questions about their products, the functionality and customizability of those products, and the applications of those products in various settings. Librarians around the country who use these products provided their own takes on how these products were working for them.
In broad terms, I found no glaring inconsistencies between the claims made by vendors for opening up their systems through APIs and the capabilities actually delivered. APIs that function as important tools and find use in strategic library projects have been created and documented, particularly in the ILS products used by large academic and municipal libraries.
We also note that the two open source systems lag behind proprietary systems in terms of customer-facing APIs that result in tangible activities that extend functionality or enable in- teroperability. While the open source model may offer many other advan- tages, we see fewer APIs designed for library customer use and a much low- er level of activi- ty among lib rari e s execut- ing projects that make use of this approach. Al- though we see many ILS prod- ucts that offer extensive APIs, we found no products that meet the ideal of comprehensive access to data and functionality through an open API. Even those with the most advanced APIs are stll not fully open systems.
Library automation systems, proprietary and open source alike, compete more and more on the basis of enabling libraries to do more with their systems. That competition for openness drives the development of the technologies that enable that capability. The reality is still a bit messy. The APIs available to library programmers continue to be quirky and less than comprehensive, even from the vendors with the strongest offerings in this area. We can also tell by the information received that vendors and libraries alike see the need to make systems more open. Hopefully, abetter reality will evolve over time.