I find it hard to imagine operating a library today without the assistance of an integrated library system (ILS). Without help from it, library work would be tedious, labor would be intensive, and patrons would be under-served in almost all respects. Given the importance of these automation systems, it's essential that they work well and deliver exactly the right functionality. I continue to hear considerable derision of the current generation of ILS products. It's human nature to focus on the problems encountered and take for granted the general success of a system. In my opinion, the major ILSs are solid automation systems for modern libraries. That said, I also believe that they continue to have some troublesome deficiencies. In this month's column I want to share some of my opinions on what's right and wrong with the ILS and also give you my view of what lies in the future. I'll speak of the systems in broad strokes, without mentioning any of the vendors and products by name.
What's Right with the ILS
The current generation of integrated library systems represents the culmination of more than 3 decades of evolution in library automation. This evolutionary path has traversed several generations of computer technologies. Mainframe systems have come and gone, terminals have made way for microcomputers, graphic interfaces have replaced text menus, and so forth. Each new round of system brought forward the functionality of the previous one and added new capabilities. The conceptual model established in the early library automation systems persists in today's systems.
The current ILS offers a sophisticated approach to automating libraries. Each module delivers a set of detailed functionalities designed to accommodate the work flows of the most complex library or group of libraries. While librarians may quibble about how any given piece of functionality works, one cannot deny the extensive capabilities of the major ILS products, especially for the treatment of traditional library materials. (We'll get to the electronic collections later.)
This functionality has been established, at least in part, through the procurement process followed by most libraries. When selecting a system, most librarians issue an RFP (request for proposals) that includes a detailed checklist of the functionality they expect. These checklists are widely shared and continuously expand. The companies that produce library automation systems know that they must be able to positively respond to all the items on the typical RFP boilerplate to successfully market their systems and they build their products to meet these specifications. So, whether one believes that the modern ILS is good or bad, it is the one that the library community as a whole has asked the vendors to build.
My Vision of an Ideal ILS
Ideally, I think an ILS should deliver comprehensive automation in an efficient manner. It must handle all the work that happens within the walls of the library and deliver services to users outside the library via the Web. An ILS must also be able to interact with other automation systems using appropriate standards and protocols. The particulars of what constitutes comprehensive automation change over time. As libraries evolve in the services they offer and the collections they build, it is essential that the ILS evolve in step. Ideally, a system's capabilities should run ahead of the curve. This happens only if the librarians themselves correctly anticipate their future needs and partner with the ILS vendors to build systems with the right capabilities for the time. It seems, unfortunately, that these capabilities lag behind the rapidly changing role of libraries.
What's Wrong with the ILS
Despite my generally positive view of the ILS, I believe that there have been some setbacks along the way and that we now face a large challenge to re-establish an environment of comprehensive automation for libraries.
The major ILS products have long done an excellent job of automating how libraries deal with traditional resources. They have fallen behind, however, in dealing with electronic content.
Since the emergence of the Web, librarians have been adding electronic resources to their collections. They have steadily increased the portion of their collection dollars invested in electronic content relative to print materials. It's my observation, however, that the tools to manage and deliver access to e-content have lagged behind library needs. Librarians created a number of ad hoc solutions to manage and to provide access to this content. They created lists of e-journals in HTML; produced locally written, database-driven e-journal locator interfaces; and kept spreadsheets of information related to their various subscriptions.
Automated solutions began to help librarians manage e-content beginning around 1999. The OpenURL specification emerged in that year, responding to the reality that static linking does not work well within the realm of electronic scholarly content. The same article might be available from multiple publishers, and it is essential to connect users to the one that is available via their libraries' subscriptions. OpenURL-based link servers pioneered by SFX are now well-established as products that libraries need to purchase as part of their strategies to manage e-resources.
Likewise, a set of metasearch products emerged so that librarians could offer their users the means to search selected portions of their electronic collections simultaneously and through a unified interface. Again, this capability stands as a separate product outside the ILS and is purchased separately.
More recently, a product genre has emerged called the electronic resource management (ERM) system. [Editor's Note: see the Nov./Dec. 2005 issue of CIL for our Helping You Buy installment on ERM.] These systems provide a specialized application for managing electronic subscriptions, which involve a number of additional complexities not applicable to print content. The ERM essentially extends the acquisitions module of the ILS to accommodate an extended set of fields specific to electronic subscriptions. I'm personally skeptical that this extended functionality should constitute a separately purchased module rather than an enhancement that would be considered part of the module's regular development cycle.
The typical library automation environment today, especially for a medium-sized to large academic library, would require an ILS to manage traditional content and a suite of additional products to lend support for electronic content. Public libraries face some of the same problems. Many now offer some sort of metasearch environment separate from their ILS and associated OPAC for searching the packages of e-content they offer.
It also seems that not all libraries find the interface offered by the standard Web-based OPAC entirely satisfactory. One of the most recent trends in the ILS product area is to provide an alternate interface instead of, or in addition to, the OPAC interface provided with the ILS. Examples include the AquaBrowser Library interface developed by Medialab Solutions in Belgium (distributed in North America by The Library Corp.) and the Guided Navigation interface from Endeca.
Path Toward Reintegration
I'm concerned that the current path of relatively nonintegrated products will not be sustainable in the longer term. Would it be better if there were an ILS that would encompass a broader set of capabilities, including one for both print and electronic content, in a more integrated package? It's a complicated issue. While some librarians may prefer to implement suites of best-of-breed applications to create their own highly customized environments, it seems that others might prefer prepackaged integrated solutions. It is a matter of degree and balance. I don't necessarily believe that a single piece of monolithic software can, or should, provide all aspects of the library's automation environment. I do, however, believe that the capabilities and scope of current ILS products have become too limited relative to the overall universe of library involvement. Why shouldn't the acquisition module of the ILS be able to handle electronic resources? Why shouldn't an ILS have native OpenURL support? Why do we need a separate system to handle e-journal holdings data?
One of the factors that I see as most problematic is a business model that favors packaging new functions as separately sold products. I recognize the reality that to survive and grow, each of the companies needs to develop new sources of revenue. I don't disagree with the notion that library automation companies deserve increased funds from libraries as the complexity of automation increases over time.
I believe it would be helpful to develop new business models that ensure adequate revenues for the companies but that mitigate the need to spin off new modules rather than extend the capabilities of the core system. I wonder if libraries would be interested in trading more aggressive pricing for an ILS that, instead of requiring users to purchase additional modules, offered a broader range of native capabilities. Many libraries put off buying supplemental modules long past their points of need due to the difficulty of raising funds. I'm not able to propose what this new business model might ultimately look like, but the current one that promotes product proliferation has serious consequences.
Let's Not Abandon the ILS
One might alternatively take the position that the very concept of the ILS is bankrupt. Under this viewpoint, each library would be responsible for assembling a set of components from multiple vendors to build an automation environment that best suits its needs. The current ILS would serve as a shrinking component of that assemblage. Let the ILS take care of backroom library functions and print resources and use other tools for managing the electronic content and for providing the interfaces used by library patrons. Such a strategy can be successful in libraries with generous technical resources. I agree that the ILS can't do everything and that many libraries have needs that require additional products and services. So while I do recognize the necessity of the dis-integrated library system to a certain degree, I continue to wish for an ILS that is well-integrated internally, that is relatively expansive in scope, and that lends itself well to integrating with external systems. In the end, I believe this will benefit libraries.
