It's a given that technology changes continually. Fve been working with automation in libraries long enough to have experienced a number of major changes in technology. I started in the days of mainframe computers, which gave way to midrange systems, which were later replaced by client/server systems. Today, the preferred technology platforms involve web-based systems, service-oriented architecture, and cloud computing. These preferences in technology shall also pass and will be replaced by new approaches to computing not yet invented.
Changes in the larger technology arena have driven library automation products in and out of favor. Each generation of technology forces some products into legacy status and offers the opportunity to develop new flagship systems designed for current hardware and software architectures. I'm concerned that in the rotation through multiple generations of technology, library automation products need to transform conceptually as well as architecturally.
I consider a legacy product to be any library automation system that is no longer receiving ongoing enhancement and development. In many cases, these systems are casualties of these technology shifts. It's often not feasible to continue to develop a system once the operating system or hardware platform on which it runs has become obsolete. In some cases, the functionality of the system can be ported to the next generation of technology. We've seen examples of some systems that have evolved through these transitions, but others have not survived. Once a company makes the decision to discontinue forward development of an ILS, I consider that ILS a legacy product. Companies usually continue to provide support services for these systems and will repair bugs and even make minor enhancements. The companies do not offer legacy products for new sales, and the installed base of libraries declines toward eventual extinction.
A flagship automation system, in contrast, benefits from new development, marketing, and support. It runs on a technology platform reasonably current for its time. Companies in the library automation industry tend to focus their efforts on a single strategic flagship ILS, though there are exceptions.
Recurring Product Cycles
A pattern I see in the history of library automation involves the launch of a new flagship ILS, its eventual demise, and its replacement by a new-generation system by the same company. This cycle may last more than a decade. If changes in technology render an ILS unsupportable, it's vital for a company to develop a new system before the old system becomes completely obsolete and its users migrate to competing systems. Flagship systems can also meet their demise as victims of mergers and acquisitions. Even if an ILS runs on a current technology platform and is otherwise a viable system, if the company that created it is acquired by a competitor, that system becomes vulnerable. Merged companies often want to channel their resources on a single flagship system. Savvy companies leverage technology cycles as they blend multiple channels of ILS customers into a single new product. Forcing lateral changes within a cycle results in abrupt changes that disrupt libraries' automation strategies. Business decisions as well as technology cycles can also place an ILS into the legacy category.
By my thinking, libraries always purchase an ILS when it is the flagship product of a company. No library would waste its resources by purchasing an automation system that was not forward -moving. But if a library finds itself in the unfortunate position of running an ILS that slips from flagship to legacy status, it faces the prospect of acquiring a new system. Most libraries have experienced the need to replace their ILS at least once during their history of automation.
Benefits Gained?
Each new generation of ILS promises many benefits that will accrue as a result of the new technology it embraces. Moving to technology platforms appropriate for the current times is essential for libraries. Each successive generation of technology brings along some new opportunities. Staying with outdated hardware or software just isn't tenable. Running a system beyond its life expectancy can isolate the library from its users, who increasingly expect to experience library services through current-day technologies.
While I can accept the reality that libraries will need to migrate through automation systems every decade or so, I would hope that libraries might gain more benefits from these traumatic transitions. Unfortunately, the transition from a legacy ILS of yesterday's technology to the flagship built with state-of-the-art components results in more of a lateral shift with little forward momentum in meaningful functionality. The development of a new automation system seems to involve pouring the functionality of the legacy systems into the new vessel, though with shiny new technology.
The style of the user interface represents one of the main differences. I've witnessed the evolution of systems from text-based menus delivered through terminals to graphical user interfaces to web-based interfaces and rich internet applications. Yet the functionality behind the interface remains much the same. It's inevitable that the functionality of the new system, especially in its early versions, lags behind the legacy product it replaces, a product that has had many years to mature with a rich set of nuanced features.
I recall when the Vanderbilt University Libraries replaced NOTIS, which ran on a costly IBM mainframe that was operated through text interfaces with a client/server system with a Windows-based graphical interface. After more than 10 years of use in our library, staff members had become experts in its terse command syntax. While the learning curve was a bit steep, an experienced operator could tab and type through the most complex task with great speed and efficiency. The new Windows-based system that replaced it involved use of the mouse and the keyboard, which just couldn't be driven as quickly. The graphical approach was easier to figure out and looked much prettier, but productivity took a dip, at least for a while. More importantly, the functionality offered in the new graphical system followed the same fundamental model as the mainframe system it replaced.
The Next Cycle to Web-Based Computing
We haven't seen the last of the migration cycles. The days of client/server systems are waning. We're now in an age of web-based cloud computing. Client/server computing evolved to take advantage of powerful desktop computers to lighten the load of overburdened servers. It was necessary to create clients for specific desktop operating systems, such as for Windows or Mac. Clients could be written in Java with its natural support for multiple platforms, but these clients are notoriously resource intensive. One of the most problematic aspects of client/ server systems involves the need to install and configure the clients on each of the computers that access the system. In large organizations, the release of a patch or a minor upgrade that has to be installed on hundreds of computers results in a major ordeal for systems administrators.
Today, servers have incredible capacity. The web browser is now the ubiquitous client, operating on everything from a desktop computer to a mobile phone. The main characteristics of computing platforms that led to client/server architectures no longer apply. Inevitably, the next generation of library automation will be web-based.
I notice that most of the new ILS products released in recent years follow this web-based architecture. The trend started early in the automation systems for K-12 school libraries, where the need for local software installed in individual school libraries and media centers placed an intolerable burden on librarians and district IT staff. Infor's recent development of V-smart, a fully web-based ILS to eventually supersede its client/server Vubis Smart product, illustrates this trend. I expect that more library automation products will transition to all web-based, staff-side interfaces over the next few years. User interfaces have been web-based for a decade, but they have not necessarily kept up with current web technologies. The current wave of new generation discovery interfaces has ushered in new products that embrace a more modern, Web 2.0 approach.
Automating New Generation Libraries
At the same time that technologies have evolved through multiple cycles, libraries have made some fundamental shifts. Collections have become increasingly electronic. Print materials, while still vital for many libraries, represent a decreasing proportion of library activities. Many libraries create and manage locally created digital collections. Services surrounding these collections take place both through the library's virtual presence on the web and in its physical facilities. Libraries share collections locally, regionally, and globally. These major changes in library strategies result in quite different requirements for automation systems than the standard set of functionality that has been poured from one generation to the next and to the next in the cycle of successive ILS products.
The key driver for the next generation of library automation, in my opinion, needs to rise out of these changes in library strategies and must break free from the cycle of just refreshing the technology. Many aspects of automation need to be re-examined in light of current library realities. While many clusters of functionality may need to persist into next-generation systems, there may be large changes needed in the overall organization of the automation framework.
I think that the combination of current technology and a fresh view of the shape of the functionality relative to library strategies can result in the next generation of library automation systems having a very positive impact on the libraries they support.
