We're seeing lots of progress as the library automation industry works toward new front-end interfaces, as I described in last month's column. Given the urgent need for interfaces that work better for library users, it makes great sense to concentrate energies on these products. But we can't let the current focus on the front-end interfaces make us complacent about the software and systems that we use to automate routine library functions.
As librarians continue to operate with sparse resources, performing ever more services with ever more diverse collections-but with no increases in staff-it's more important than ever to have automation tools that provide the most effective assistance possible. Contrary to many who say that the ILS is becoming irrelevant, I believe that it's more essential now than ever before. No organization can operate well today without systems to automate its basic operations.
I see now as a great time to begin thinking about what librarians should expect out of the next generation of automation systems. Since we are in a phase of concerted development of front-end interfaces, we'll soon face the need to catch up on the ILS side of things. I think that librarians would do well to spend some time brainstorming about their fundamental automation needs and what the ILS needs to become in the future. We need to come to grips with how automation systems should work, especially in light of three things:
- Increased digital collections
- Changed expectations regarding interfaces
- Shifted attitudes toward more openness of data and software
I anticipate that the next cycle of library automation developments will focus more on the ILS, but hopefully in a completely redefined form.
The next-generation library interfaces work fairly independently from the integrated library systems that automate our operations. We're hearing a lot about the decoupling of the front-end interface from the back-end ILS. The new front ends rely on the data managed within the ILS and have many points of interoperability, such as those needed to display the current status of library materials and to enable services like holds and recalls. No longer is there a static one-to-one relationship between the interface and the ILS. The current vision of the interface spans a suite of content repositories. The ILS stands as only one of many components that contribute content and services to the next generation of interfaces. Today, it's becoming much more common to think of the front-end interface independently of the ILS.
Breaking Out of Aging Molds
The basic structure of today's ILS was cast more than 20 years ago. The fundamentals of the relationships among the core databases and the modules that surround them haven't changed much, so today's products follow a structure designed back in the days when libraries dealt exclusively with physical collections. In the last decade, libraries have been transformed radically by electronic services, but automation systems haven't made the bold shifts in functionality necessary to stay in tune with the large-scale changes in collections.
I see that the current generation of ILS products needs considerable transformation. Will incremental improvements in the ILSs being used today adequately serve the needs of libraries into the future? Or do we need a more radical approach? I lean toward the view that we need to substantially reshape at least parts of the broad functionality of the ILS.
The next generation of library automation systems needs to be designed to match the workfLows of today's libraries, which manage both digital and print resources. In order to provide efficient and effective support, the software needs to be designed around the processes and tasks that meet the goals of the organization. In broad terms, I think that the current slate of ILS products works on many assumptions about library workflows that have long since changed. The next generation would benefit from a thorough re-examination of the day-to-day work that takes place inside libraries. That process may be confounded by the fact that many librarians have adapted their workfLows to match the limitations of their automation systems. A fresh look might call for a more idealized approach, looking beyond practices that have been shaped around the capabilities of the automation systems and concentrating on the most efficient ways to accomplish the work of the library.
Dissatisfaction With the Current Status Quo
I'm in the process of carrying out a survey that solicits information from librarians regarding their attitudes toward their automation systems and the vendors that support them. The initial, tentative results reveal a high degree of dissatisfaction with the current commercial options. I'll be performing a more detailed analysis on the data, attempting to correlate satisfaction levels by product and company. At this point, I think that it's safe to say that librarians expect more than they are currently receiving from their automation products.
They're also frustrated by proprietary systems. We can no longer deny the trend toward the open source ILS products. We're seeing completed implementations, commitments for future migration, and widespread interest in open source alternatives. The support voiced for open source solutions seems to reflect a low level of trust in commercial companies and strong interest in gaining more control of critical systems. So it seems reasonable to expect that the next generation of ILS products will include open source alternatives.
Librarians' demand for openness focuses on the data as much as the software. The commercial proprietary systems can go a long way toward meeting expectations for openness by making sure that all of a library's data and the detailed functions of the software are made available through an application programming interface. A well-documented API gives the library much more flexibility in creating new services beyond what comes delivered in the system. Taking advantage of an API generally requires a programmer to write software that interacts with the ILS through the API to deliver these extended functions. Many of the current systems already offer APIs, reflecting a willingness among the players to take this first step toward openness.
Gaps in Functionality
Back when librarians dealt exclusively with print, the ILS did a pretty good job. But as the field shifted toward digital content and services, gaps emerged between the functionality of the ILSs and the real world they were used in. Many gaps remain unaddressed by the current vision of the ILS, including collection development, ILL, preservation (both digital and physical), and remote storage operations.
Despite having mind-numbing complexity and abundant features in some areas, automation systems continue to be bound to many aspects of library operations that have changed since the die of the ILS was originally cast. So I think that an important goal of the next generation of the ILS would be closing those gaps in functionality.
What About a More Lightweight Approach?
Many of the current generation of ILSs can be characterized as large, monolithic systems. They have accumulated layer upon layer of functionality over the years, resulting in complex systems that offer an incredible number of individual features. One of the chief complaints today is that an ILS places large burdens on the customers for installation, configuration, training, and administration.
I think of the ILS as a business automation system that supports the ever-evolving mission of libraries. Since one key trend in the broader IT realm involves service-oriented architecture, it stands to reason that if library automation systems evolved toward service-oriented business applications, they'd be more able to support libraries as their internal operations evolve. Libraries, like other businesses, increasingly require dynamic interactivity with the business and information systems of their higher-level organizations and with their peer institutions.
In contrast to the current monolithic approach, we might consider the ILS as a suite of lightweight applications woven together in a service-oriented architecture. This approach will have both the flexibility necessary to meet our automation needs and the openness that we increasingly expect.
Opportunities for Change
When I think about the state of the ILS, I see tremendous opportunities for a new generation of products more closely matched to today's workflow that will help libraries function more efficiently. I don't necessarily expect a new crop of systems to spring up overnight, but it seems to me that the time is approaching for next-generation ILS products to start taking shape.
The previous cycles of ILS replacement mostly involved bringing forward the functionality of the previous generation onto a technology platform consistent with current times. I hope that the next round involves both a major rethinking of the functionality as well as a move to today's Web services architecture. I think that the key to progress in library automation systems involves improving technology infrastructure and reshaping the functionality to match today's real-world libraries, then adding enough flexibility to accommodate future changes, which seem likely to unfold more rapidly than ever before.