Copyright (c) 2005 Information Today
|Breeding makes some forecasts about what might play out in the next few years as he observes the current state of the art in library automation. One could argue that library automation cannot and should not exist as an independent endeavor. Rather, it needs to be tightly integrated with the other business systems of an organization.|
I'm often called on to give my opinions on the future of technology in libraries. While I don't claim to be an expert in all areas of technology, I do spend quite a bit of time watching the progress of software developed for libraries and tracking what systems libraries select. As I observed the current state of the art in library automation, trends occurring in five areas led me to make the following forecasts about what might play out in the next few years.
1. The integrated library system (ILS) will be reintegrated. I find myself still bemoaning the lack of comprehensive library automation systems. Today's top-of-the-line systems offer great functionality for managing print materials, but they don't offer the same degree of sophistication for handling electronic content. Librarians must buy and implement whole suites of add-ons in order to provide the back-end management functions and front-end delivery systems for their electronic collections.
Library collections have evolved to include an increasing amount of electronic content. It hasn't been a secret, and it hasn't been all that recent. Yet the tools to help librarians manage that content are just emerging. And rather than being integrated within the automation systems we already have, these tools are packaged as separate applications that require significant time for installation, configuration, and ongoing operation.
I don't disagree that as the scope and complexity of the ILS expands, the costs should increase. But librarians should be able to choose whether to buy modules for Open-URL linking, electronic resource management (ERM), or federated search in the same way that they might choose to opt out of acquisitions or serials control.
My main complaint isn't that link resolvers, ERM systems, and metasearch interfaces are packaged as separate products; it's that they are not easily integrated with the other components of the library's automation environment. In many cases, even when the product has been developed by the same vendor as the ILS, it's based on an entirely different database architecture, or even a completely different database product. In an era where the general trend is to consolidate all of an organization's business systems into a single database environment, the tendency for library automation components to rely on different ones goes against the grain. In order to achieve better integration, components should share existing authentication and authorization services; follow the n-tier architecture so they can operate with whatever hardware platform, operating system, or database the library prefers; and rely on Web services to retrieve or reference data as needed from other applications rather than replicate entire data sets.
I would like to believe that both the companies that produce these systems and the librarians who buy them see them as an interim solution. As these products mature, I optimistically believe that we will see them reshaped into a coherent architecture.
2. The business landscape will change. A broad look at the slate of companies developing library software reveals a fragmented industry, consisting of a number of companies struggling to increase their slice of a fairly small economic pie. This fragmentation has both a positive and a negative effect. On the positive side, having multiple companies in vigorous competition motivates each to pursue aggressive development strategies. As a result, there are a number of systems available in each sector of the market-and librarians appreciate having those choices.
On the negative side, industry fragmentation results in each of the companies spending development energies creating very similar systems. The expected functionality of an automation system has been firmly established, and the ones that are available are much more alike than they are different. As I've said and written many times, I believe that the way that librarians use boilerplate requests for proposals has led to a homogenization of the ILS and has dampened developers' abilities to make innovative breakthroughs.
Mergers and acquisitions also have positive and negative effects. On the negative side, one competitor taking over a rival almost always results in fewer systems and in some libraries having to change automation systems that otherwise would have stayed put. On the positive side, vendor consolidation allows a company to assemble a larger development organization that is capable of creating better software at a more rapid pace than is possible when so many companies are duplicating each other's efforts. We can only hope that companies will exercise this opportunity if and when consolidation occurs.
From that perspective, our current fragmented industry has resulted in the development of at least half a dozen really good, feature-rich library automation systems. But a consolidated industry might result in fewer systems that are more technically sophisticated. With the recent ambitions of Google and its competitors coming to light, we need all the help that we can get in acquiring technologies that will strengthen the library's position relative to commercial alternatives.
Although this has been predicted for years, I still believe that there will be another round of vendor consolidation in the library automation industry. It could happen before this column makes it to press, or it could brew for another year or two, but expect some change in the business landscape, whether it's a minor reshuffling or a major restructuring of the industry players.
3. Players in broader industries will become involved. In addition to the possibility that some changes might occur among the companies that have historically been involved in library automation, I also believe that, at some point, companies in other sectors with overlapping interests will become involved.
We've already seen some examples: Follett and Sagebrush have library automation divisions, but they are also engaged in a number of other business activities related to education. Geac has evolved into a company that produces software for very broad industry sectors; its library automation division is a very small corner of the company. Endeavor lives within Elsevier, one of the largest multinational publishing firms in the world. BiblioMondo was recently absorbed by ISACSOFT, a company with broad ambitions in e-learning technologies.
In each of these cases, a larger company sees library automation as a profitable avenue for its broader interests. I wouldn't be surprised to see additional movements in this direction. It would be natural for a company developing course management or student portal applications to see library automation as an extension of its core products. Likewise, the companies that develop enterprise resource planning or other enterpriselevel applications for colleges and universities might also be interested in extending their framework to libraries.
One could argue that library automation cannot and should not exist as an independent endeavor. Rather, it needs to be tightly integrated with the other business systems of an organization. In an ideal world, housing "integrated" library systems within the framework of other enterprise-level systems would allow the library to operate more efficiently and be more responsive to the goals of the larger organization. On the other hand, enterprise systems can be complex and unwieldy, and many organizations have gone through considerable difficulties implementing and maintaining them. Given the complexities of our automation needs, such a marriage would bring mixed blessings.
4. Libraries will consolidate automation efforts. As I study the procurement patterns of automation systems, I notice a definite trend toward more shared implementations. Libraries are increasingly banding together in consortia to share a system. Several factors underlie this trend.
For one thing, today's hardware and software platforms can scale up to support very large systems. In times past, there was good reason to be concerned about assembling server hardware capable of standing up to an ILS shared by a large number of libraries. In today's environment, however, such hardware is readily available.
Libraries can also save considerable software, personnel, and administrative costs and focus their resources on other priorities by taking advantage of a shared system. The technical staff needed to support the ILS can be provided by the consortium, with the costs allocated to each member. Libraries can also benefit from shared acquisitions, cataloging, and other technical processing operations. This permits staff to focus on enhancing services and to concentrate on improving the infrastructure for electronic resources.
In addition, large-scale shared systems tend to be professionally managed and housed in industry-standard facilities, complete with suitable cooling equipment, power protection, physical security, and continuous monitoring. Individual library implementations tend to be run more informally, often on a shoestring budget. Moving to a shared system can reduce the risks of data loss or service interruption.
K-12 and special libraries have also undergone a major shift toward consolidated systems. In the K-12 arena, the dominant approach in previous years was to install a PC-based automation system in each school's library. In the last 2 years, things have changed dramatically as school districts insist on centralized automation systems serving all the libraries within a jurisdiction. Likewise, in the corporate world, there has been a shift to enterprise-level systems serving all of a company's locations.
The most significant benefit of shared systems, however, lies in the ability to get more mileage out of collections. With today's tight budgets, most libraries work hard to stretch collection dollars and to avoid duplication among the consortia members. A shared automation environment can help provide the infrastructure to share a distributed collection efficiently while ensuring that materials can be provided to library users quickly.
For all of these reasons, the trend toward shared systems continues to grow. Although these systems have been around since the early days of library automation, in recent years, the number of libraries choosing them has increased. More independent libraries have joined consortia, and some consortia have merged. Libraries within affiliated college or university systems are more likely to partner in a shared system than they are to go with individual ones. In the next few years, I expect to see the number of ILS installations decline.
5. Commercial systems will continue to dominate. I keep watching for movement toward open source (OS) library automation systems. It still isn't really happening. As I track the systems selected by public, academic, school, and special libraries, I see that, overwhelmingly, most choose commercial ones even though librarians and library technical staff tend to favor the OS approach strongly. Open source software gets considerable use with several library components including link resolvers, institutional repositories, personalized library portals, and infrastructure components such as the Apache Web server and the Linux operating system, but not with the core automation system.
There are OS options available. Libraries throughout the world, including a few in the U.S., are using the Koha automation system. But the numbers are tiny compared to those using commercial alternatives. So far, at least, the adoption rate of OS systems is very low. I always solicit librarians who use these systems to let me know so that I can track them in the lib-web-cats directory. Drop me an e-mail if your OS ILS isn't listed.
One project to watch is Georgia PINES. Its goal is to create an open source ILS to replace the commercial system that supports Georgia's more than 200 public libraries. Work is well underway; the initial alpha release of the software, called Evergreen, is expected in July, with full production planned for fall of 2006. The project's progress is documented at http://www.open-ils .org. Successful execution of this project would be a major boost in confidence for OS systems.
Will libraries move to open source systems in great numbers in the next few years? One possibility is for these systems to reach a tipping point so that OS adoption will become more widespread. Short of a major change in library procurement preferences, however, it seems more likely that the current course, where commercial systems dominate, will prevail.
Whether or not any of these forecasts prove correct, I hope that I've outlined a range of possibilities based on empirical observations. Keep in mind that these are just my personal opinions-and that my crystal ball can be way out of focus.
|Type of Material:||Article|
Computers in Libraries|
|Volume 25 Number 5|
|Systems Librarian Column|
|Last Update:||2012-12-29 14:06:47|
|Date Created:||0000-00-00 00:00:00|