Eric Morgan and I took a one day trip up to Windsor, Ontario this November to attend a special ILS Symposium hosted at the Windsor Hilton by the University of Windsor, which was organized by Gwendolyn Ebbett and Art Rhyno of the U of W. Art Rhyno has, of course, been very influential in the library community both as a "gadfly" and as an innovator in the field of library technology. The opportunity allowed me to converse with and learn from folks in Canada (primarily) who have a stake in, and a keen interest regarding, the future of the integrated library system (or ILS). The symposium was organized very well, and each speaker or group of presenters had very interesting things to talk about in order to jump start this conversation. Eric and I noted that while what was said is not entirely new, this is an important continuation of conversations that have been going on for several years now.
Among those who presented were Art Rhyno, Peter Murray, the Evergreen / PINES developers and administrators as well as Alan Darnell who has worked on the Ontario Scholars Portal. During the initial reception the evening prior to the symposium, we were able to meet several folks from around Canada who have been working with many different ILS vendors including SirsiDynix, Ex Libris, Endeavor Information Systems, Follett and others. It became clear during our discussions that libraries of all levels share similar concerns about the future of the ILS and related commonly used products such as federated search engines, digital repositories, and associated public interfaces. There's such a convergence of factors going on with the continuing rapid explosion of web based information and tools, that it's hard for the library profession to stay on the cutting edge. So, the questions that were being asked were not only "Can we do anything about this?", but also "Are there directions we haven't thought of?" and "What is feasible in the library and academic professions?"
Art Rhyno was the first formal presenter at the symposium. Art is very talented at creating analogies which help to explain very complex situations, namely the situation librarians find themselves in right now with the breakdown of the traditional ILS / OPAC. The analogy he used was the evolving nature of the American automobile. In the 1960's, automobiles were still evolving and being marketed within a technological environment that was for the most part, analog. The engine of a Mustang was composed of moving parts, hoses, belts, and wires. The engine could be easily understood by anyone with at least some interest in mechanical issues, and they could be instructed on how to modify or tweak the engine to fix it or to enhance it. As the auto engine has grown more complex, the support structures required to maintain the same level of performance and reliability have grown in the auto industry, the auto repair industry, and to a certain extent among the armchair mechanics. With most new engines being controlled by one or more computer chips, the auto repair industry has developed sophisticated tools that can be used to diagnose problems and facilitate repairs. These same tools can be used to tune engines so that they run at peak performance. The same has not been true in the library ILS industry. As needs and complexity has grown, the industry has not been able to develop structures which allow the systems the flexibility required to meet increasing expectations. ILS vendors are so busy trying to build in the latest requirement or tool, that they have fallen behind on service and support, and the ability to respond quickly to a rapidly changing information landscape.
In other words, as Art puts it, the "support ecosystem" has not evolved in parallel with the increasing complexity of the ILS and the demands of the patrons who ultimately use these systems. Those demands have grown exponentially over the last 10 years. The ILS has been expected to maintain the same back end complexity to support processes like acquisitions (a business model), circulation, interlibrary loan and cataloging while also become more like Google, Amazon, Wikipedia and Flickr. So, Art had some suggestions on what might become the building blocks for the next generation ILS. I should point out, though, that he is not opposed to vendor supplied solutions. However, the suggestions he does make do for the most part, find their home in the open source software community.
Art's first suggestion is that we let the specialists handle those aspects of the ILS which are not a librarian's forte. For example, the acquisitions system is really a business model that has its own level of complexity and standards. He proposes that we look into adopting as the core of the business end of the ILS a system such as OFBiz, which is an ERP system (enterprise resource planning) that is currently in the final stages of the Apache Incubator project. Companies such as JD Edwards (PeopleSoft) - EnterpriseOne have adopted similar models in their ERP systems. Art proposes that instead of including such complexity as a core feature of a monolithic ILS, we modularize such components and allow those who are experts at this sort of software handle that component so that the "ILS" can utilize forward looking business models with state of the art ERP components...in other words major on the majors and minor on the minors.
He also suggests that we incorporate, again in a modular way, such key components of an ILS/OPAC as indexing, products such as Lucene which is considered to be a gold standard for indexing almost anything today. In fact, it is already being used in vendor products by such companies as Ex Libris and Endeavor for several of their product line. Other organizations such as the Center for Natural Language Processing have also adopted Lucene.
Art also suggested that perhaps a culture change needs to take root in academic and public libraries. He encourages participation in conferences such as Code4Lib where library technologists can gather and participate in "hack fests" to increase their technology skill levels and collaborate with others of a similar bent. This can be likened to "barn building" in an Amish community. Instead of a few people going the long mile alone, several people with various skill levels can contribute to the overall construction of an ILS. They gather (in a virtual or real sense) for a common task, they build skills and they create a very stable product. This will obviously take time and effort, and commitment on the part of library administrative personnel. But in the long run, Art sees this as one of the only viable and sustainable alternatives we have available to us.
Peter Murray gave the second presentation. I found him to be very engaging and lively. He has obviously been thinking about this issue for a very long time. Peter hails from OhioLINK (The Ohio Library and Information Network) and is the assistant director for multimedia systems. Peter is very passionate about SOA (service oriented architectures). As Peter defines it, SOA is:
The key point about Peter's presentation was that we need to extract ourselves from the mindset that believes that a large monolithic system will solve all of our problems.
The SOA approach is not opposed to making use of an inner core of services provided by an ILS, whether vendor supplied or not. In fact, as was pointed out earlier, the idea of reuse is central to SOA. Legacy applications may play a very important role in our service architecture. However, no one component of a service architecture should be considered irreplaceable. Since the design principle recommends that the systems we integrate should be protocol agnostic and programming language agnostic, the various components of our services should be interchangeable with similar systems. And, while web services can act as a glue for integrating the various pieces, the mechanisms and the methodologies for those web services are a means and not an end. While SOA is a blueprint for design, web services is analogous to the plumbing. This is why open standards and open protocols are important and should be adhered to. As long as the standards are maintained, the components that combine to form an SOA design can be truly modular.
Therefore, the key to a new model for the ILS is taking out the "i" from "ils". What Peter suggests is that we move forward with orchestrated disintegration. We need to have the freedom and the flexibility to respond to the rapidly changing information landscape. During Peter's talk, I was reminded of the move from the monolithic mainframe computer to client-server architecture, and what a revolution that was in computing. This is the same technology that makes the Internet work the way it does. And, increasingly, this is the way successful dot-com businesses have survived over the last ten years. For example, when someone goes to the homepage of Amazon, all of the content on that page is not coming from one machine, let alone one application. There are several layered SOA applications working in the background to build that page, or any page on Amazon's site. For example, there is a recommendation service. There is a review service. There is an inventory service, a personalization service, a shipping service, a financial service, etc. The place for integration is not on the back end, where one machine or one monolithic application is responsible for creating the user experience. This not only allows for greater performance and variety, it allows sites such as Amazon to compete by being able to very quickly prototype and plug in a very wide array of services for their customers, maximizing the customer experience.
Thus, the "ILS" would become a constellation of services such as circulation, resource description, resource discovery, acquisitions services, etc. These services can be housed at one location or many, on one set of machines or many, using heterogeneous technologies all taking advantage of open protocols and standards. It seems as though it would be prudent for libraries to investigate this approach in order to attain the highest levels of flexibility and responsiveness to patron needs.
The third presentation was given in the early afternoon by the PINES consortium / Evergreen development group. David Singleton, the deputy state librarian for the state of Georgia first gave a brief history of PINES, which began as a white paper in 1998 regarding a study for implementing a state wide library card. By the spring of 1999, funding and a mandate for a state wide ILS had been given, requiring a new system to be online by December of 1999. The state chose Sirsi as the ILS vendor to use for this project. Almost immediately, they found that they were having scalability problems serving almost the entire state of Georgia. Since late 1999 and now, they conceived and developed the Evergreen system, which is (potentially) and open source ILS system serving over 44 public library systems in the state of Georgia (and growing). The work on this system was done by a team of four developers. The system manages over 8 million items, and recently handled over 452,000 ILL loans (up from 6000 per year prior to Evergreen).
Initially, the system requirements for Evergreen included:
In July 2005, an alpha version of Evergreen was available and being tested. In early 2006, they went beta. Since September 2006, PINES / Evergreen has been online. The projected hardware cost for a new Sirsi system (in order to upgrade from the older Sun Microsystems based computer they were using), would have cost them over $1.5 million dollars. The current Evergreen system runs on commodity hardware of over 20 machines, two switches, and two firewall / load balancers costs around $350,000. The core technologies include Postgresql, Perl and some C libraries and utilities, Apache, mod_perl, client XUL libraries and a messaging client / server called Jabber. The operating systems are all Linux (Debian).
Evergreen seems to follow the SOA model in a few respects. It's underlying architecture is very distributed, with load balancing elements built in. A cluster of 16 machines forms the core backbone for the central services, with each node mirroring the applications of any other node. There is also a separate set of nodes responsible solely for database access, and they are connected to a SAN (storage area network). They also developed a protocol called OpenSRF which is a framework allowing multitasking between the clustered machines. This allows for vastly increased throughput. However, it also allows the applications to cooperate, and serve services to the client on an as needed basis. The "OPAC" for Evergreen is really an aggregation of these services, similar to Amazon. This allows the developers to introduce components into their service architecture without needing to redesign production components.
Right now, Evergreen handles primarily circulation, ILL, OPAC and holds for the ILS (as well as cataloging functionality, I believe). In the future, they plan to add in serials, acquisitions, online bill pay, a children's portal, foreign language translations and social aspecs which include reviews, recommendations, etc.
Alan Darnell, who is the project manager for the Scholarly Information Resources Project in Canada, spoke about the content that may go into the next generation ILS. The Scholar's Portal is a container for more than 150 million records, which includes over 10 million full text articles. Alan and his team basically took the metadata content for these citations along with the full text, and create a "federated content" engine, as opposed to "federated search". With this experience as a backdrop, Alan pointed out that journal content is the "prodigal son" of the library world, because traditionally libraries have housed copies of this content on the premises of the library, where bound volumes were stored. With the rapid advent of electronic journals, serial content "left" the library and was housed elsewhere, primarily with vendors. And so, Alan is proposing that the "prodigal" journal content return to libraries as content for our next generation ILS. We need to figure out how to combine traditional cataloged content with services such as functional relevance ranking, component architectures, digital objects and commercial content.
The core of the traditional catalog should be enhanced, according to Alan, to include information such as TOC (table of contents), cover images, review services, etc. He also suggests that it would be helpful to patrons to have metadata and full text broken down into component parts such as chapters and paragraphs (ala Amazon). Then, layered services can be built on this core which take advantage of external applications, whether on site or off site. In this way, and utilizing something very similar to the SOA architecture proposed by Peter Murray, various "views" of the content could be created dynamically in order to cater to different audiences. For example, we could create a Wikipedia view, an Amazon view, a Google view, an images view, and even a traditional OPAC view. This takes the service model out one level of abstraction because each view could also be composed of an aggregate of services, and each view represents another level of service. Both this and the SOA concepts really appealed to me.
How do we move forward? A panel discussion composed of all of the presenters at the symposium was held after the final presentation. Several great suggestions were made both by the panelists as well as the audience. Several of these suggestions included: building a community and a critical mass, similar to the Apache Incubator project; having conversations on important issues like standards with folks outside of the library community (e.g. - the standards committees themselves as well as vendors); we need to both evolve as libraries and integrate outside professional services (such as ERP systems) into our architectures and workflows; we need to build expertise within the library community so that we can steer our own ship in the technology field; we need to maintain the good traditions that have been built up in the library community; and finally we need to "know the user" and regularly do usability studies.
All of these were great suggestions. Gwendolyn Ebbett's wrap up session after the symposium was a very fitting summary, because she described the conversations that had taken place there, the conversations that had occurred long before the symposium, and the initial steps to be taken as a "good beginning". And, Art Rhyno's repeated suggestion that we take the "Amish" approach to barn building by incorporating folks with very different sets of skills, and at different skill levels, into the process of building successful ILS systems was very helpful and encouraging. Georgia has demonstrated, I think successfully, that we can do this. Making the sorts of changes required to move forward will not be easy, but they are most assuredly necessary.
Site Last Modified:
Tuesday, March 13, 2007
All libraries:
Architecture | Art
Image | Business Information Center
| Chemistry & Physics
| Engineering | Hesburgh
(Main)
Kellogg/Kroc Information Center |
Life Sciences | Mathematics
| Rare
Books & Special Collections | Radiation
Lab | Kresge Law
