Equinox Blog

[Apologies for reposting but I forgot the Creative Commons license on both formats and the acknowledgments on the PDF. Those are the only changes in this version.]

[This post is also available as a pdf (310 KB)

We have seen two kinds of consortial migrations to Evergreen: new consortia where formerly separate libraries join together to use Evergreen—commonly with a shared union catalog—and existing consortia that move from legacy software to Evergreen. Historically, new consortia have been more common although there are currently a few major migrations of existing consortia to Evergreen in various stages of planning. Most of this post deals with issues involved in creating new Evergreen consortia.

This post also assumes that the consortium will be used to share resources within the member libraries. There are Evergreen consortia which limit resource sharing in various ways so these observations may not apply in individual situations. YMMV.

Evergreen is the first library software designed to run large, geographically-dispersed, resource-sharing networks. It is a new thing. Originally developed to run PINES, the Georgia public library network, Evergreen has proved to be popular, robust, and scalable. The fact that it is the first of a new breed of software, the demand for it from consortia that want to share resources has been gratifying. Mind, Evergreen is perfectly happy to run small libraries because it uses modern software practices but it was designed to manage large collections of libraries and that is our focus here.

What do you need to think about if you are contemplating moving to this kind of network for your libraries?

GOVERNANCE
The new consortium will need a structure for planning, decision making, and maintaining the integrity of catalog records, technical support, policy formulation, and financial details. Each Evergreen consortium does these functions some way but those ways vary greatly.

MIGRATING RECORDS
Various types of records can be migrated, including authority, bibliographic, item, patron, and circulation transaction records. When a group of libraries is brought together into a new Evergreen database, overlapping records have to be dealt with. Since bibliographic and patron records are the two types of records that most commonly have duplication in this situation, special considerations apply.

The records will be in the databases of the systems you are moving the libraries from and those records must be copied out of the legacy system and into Evergreen. This process involves understanding the structure and format of the records, the libraries, and the policies of the libraries. When these factors are understood, programs can be written that translate the data structures of those records to Evergreen databases. This is a procedure that requires patience and skill.

Making this process more complex is that in forming a consortium, the migration will often mean that records will be moved from a variety of legacy systems, each with different data structures. Moreover, an issue for the new consortium may include dealing with records of varying quality.

The records from different, previously separate libraries will be joined with those of others. If there is to be a union catalog, deduplication of the bibliographic records is recommended. “Deduping” is a process which groups the same bibliographic items in one bibliographic record with the various libraries holding that item listed by the entry. Done well, deduping will result in a catalog which is easier to use and more accurate.

Deduping is complex and given that cataloging and patron records are often of differing quality from the different libraries. Deduping takes a judicious mixture of programming and detailed examination of the various records. Normally, catalogers will make the final decisions with bibliographic records.

Given that so much of the use of a modern library begins with queries to the catalog database, the more accurate and fuller these cataloging records, the better. One approach is to have these bibliographic records upgraded either by independent firms specializing in this service or by those doing the migration itself. And here, too, there are choices: is it better to upgrade records before the migration or after? There is as yet no standard of practice to give guidance to this question.

POOLING PATRON RECORDS
Patron records do not have a standard such as the MARC, hence, the quality, use, structure, and local requirements vary enormously.

Will you have a single borrower card for the whole consortium or are the users keeping their old cards? If the latter, do patron barcodes overlap? If so, something will have to be done-either redoing the numbers or issuing new cards for the same reasons that items cannot share barcodes, neither can patrons. Barcodes/RFID tags are discussed below further.

If you are issuing new cards, this is normally done when the patron’s library goes live in Evergreen. It is a simple process. Do you want the patron records deduped? Patrons will frequently have multiple cards from other members in the new consortium.

Many consortia issue cards as the consortium adds member libraries so this is the perfect time to introduce your new, spiffy, single borrower card.

Typically, consortia will bring over patron names, patron barcodes, and address information. Other information might include current items checked out and fines but these data frequently do not come from patron files but, rather, come from other files for which there are usually non-standard formats. This information normally takes time and thought because these formats have to be understood. Often fines will be brought over only above some amount.

Do you want the records checked in the change of address registry? In the U.S., the Post Office maintains this registry and it is a method for looking for patrons who have moved in order to remove them from your current patron records.

Even given all these considerations, public libraries patron records are relatively uniform compared to academic libraries. Academic libraries often get their user records from the central administrative entity such as the institution’s registrar and updating practices vary, too.

POLICIES
An important set of questions that all consortia must consider revolves around policies. Will all libraries in the consortium have the same checkout policies (for example, books circulate for 2 weeks, one renewal, etc.) or will each have separate policies?

Consortia in which all members have the same policies will often discuss this configuration choice in terms of a “common user experience.” Consortia in which members have different policies might discuss this type of configuration in terms of flexibility for its member libraries. The former is simpler for the migration team; the latter may be easier for the new consortium-but is complex for the migration team.

Policies are a part of the Evergreen basic configuration. This part of migration also involves matters such as setting up the organizational units for each of the members (for example, a system’s branches); OPAC customization; setting up SIP services if required, and other such details necessary to customize the Evergreen implementation for the consortium’s members.

BARCODES/RFID
As a part of pooling records, item barcodes from the various libraries joining the consortium have to be studied to make sure that there is no overlap. Two different items cannot have the same ID number, so in an Evergreen union catalog, each item and each patron must have a unique identifier. If you have overlapping barcodes in the various collections, some items will have to be rebarcoded. Fortunately, we at Equinox and a partner have developed an improved method to rebarcode collections. Reading barcodes or RFID tags, the same issue is involved as RFID tags at their core simply relate the barcode number to the ILS, where an overlapping barcode will exist. There are alternative solutions to re-barcoding the collection available through RFID technology and may be worked through with the RFID vendor and Equinox at migration.

SERVERS
We will be happy to recommend a server configuration. Evergreen server configurations follow modern practice and will tend to use a number of redundant, “commodity” boxes, typically not immensely expensive as was the practice in the past. We will give you some specs and you can buy them yourself. Usually, the libraries we deal with will not pay taxes and can get these servers cheaper than we can as a result although recently we have found that our purchasing of large servers for our hosted customers has resulted in scale economies-the lower cost of these big servers is often cheaper than smaller servers even without taxes.

We also have libraries that have us host their libraries’ catalogs for reasons of convenience. Hosting allows the libraries to concentrate on offering library service, without having to worry about servers, power, bandwidth, backups, and the like.

The server configurations we suggest tend to be quite robust. By that we mean that the configuration is fault-tolerant and will not likely go down because if one server dies, the others can take up the slack. You can save money by buying fewer servers with the attendant risk that at times the configuration may go down in production. The software is also robust and failure is rare. However, with a more robust configuration it is rarer, still.

Because of the software architecture of Evergreen-most notably the OpenSRF piece-Evergreen is scalable. You will find that use of the collection will increase-particularly in a public library-so the demand on your servers will increase. Upgrading is relatively easy: buy more of these “commodity” servers, add it to your server cluster, put Evergreen on it, and you have upgraded.

And if you are thinking of buying servers to run Evergreen, PLEASE talk to us. A common error used to be to buy or attempt to use inadequate or misconfigured equipment. Fortunately, that problem does not arise much these days as an understanding of modern server configuration becomes common. And we are working on a document that will discuss Evergreen servers in a bit more detail.

Typically, users who buy their own servers will have us configure them remotely, then, commonly, we migrate the records into the new servers but these practices also vary widely. The Evergreen community has a number of members who manage their implementations from migration to support and others who pick and choose which parts of their Evergreen instance they will manage and which parts they will rely on others for. You are free to do what suits your purposes. It should be clear, however, that the whole process involves considerable technical expertise, experience, and attention to detail.

COURIER SERVICES
Moving materials around in a resource-sharing consortium is a complex undertaking. Users like this service and it will grow as these users discover it. When PINES moved from its legacy ILS to Evergreen, the number of these “holds” increased about 40% over the year. There are also similar anecdotes from other consortia. The logistical questions of running a large, geographically-dispersed courier service are not trivial-particularly with a 40% increase in traffic. PINES at one time considered hiring a logistics expert, for example, before the problems with the economy intervened. Logistics is one of those things in life that takes someone with experience to do well.

NETWORKS AND CONNECTIVITY
Libraries today require connections to the Internet and to other network services. Evergreen is no different and running a resource-sharing consortium has network implications also. One important issue is the fact that the move to Evergreen apparently results in an increase in network traffic similar to that seen with holds mentioned above. Predicting where and how is not currently possible but, we hope, in time-and with enough data-that it will be. Second, the network will require monitoring as the Evergreen consortium grows. Bottlenecks move around. If you add bandwidth here, then, in time, a bit more will be needed there.

SUPPORT
How much support will you be need? And what type?

Support can be for hardware and software and it can be for system capabilities. We do both and will quote you a price for either based on our anticipation of how much support you will need. For larger installations we will assume that you will supply “Tier 1″ support-that is, basic trouble shooting and functionality. Is the computer plugged in and help on “how do I check out a book?”

Of course, as an open source project, Evergreen has a community of users and the various mailing lists used by the are a key source of information and help.

We also find that libraries running Evergreen will opt for high levels of support the first year or two then, as they learn the system better, they take over more of the support functions and save money that way. How much of these support functions your group will take over is a training question.

TRAINING
Training is a complex issue and one that involves not only Evergreen functional training for day-to-day operations but it also involves strategic considerations. There is a lot to think about.

There are consortia running Evergreen which are completely independent of external support except through community resources. And, there are consortia moving from having external support to independence—and anywhere in between. Given that Evergreen is an open source project, your group can plan on and work towards independence and many prefer this option for reasons of cost, control over their environment, and continuity of their software environment. If independence is your goal, you will need more advanced training certainly in Evergreen systems administration and probably migration.

COSTS
What will Evergreen cost? It depends.

It depends on the decisions you make among the array of choices outlined here and also on the number, size, and configurations of the libraries you are joining in your consortium. For us to give you the costs, we need some basic data on these libraries which is why we ask for them. We will typically need to know:

• the libraries being migrated
• the number of branches
• the number of bibliographic records at each
• the number of annual circulations
• the number of patrons
• the number of policies your libraries will have and an understanding of SIP requirements
• the legacy ILS you will be migrating from

You will also need to know about your barcode/RFID ranges of consortium members.

WHAT NEXT?
Ready to move to the future?

We will prepare a proposal and you or your group will choose what you want to do. You will likely have questions when you get our estimates and we can use those questions to get a better idea of what you want and, perhaps, to suggest alternatives.

After the details have been worked out, we will send you a contract that spells out what we have agreed on in legal terms. Your lawyers will look at it and suggest changes. Our lawyers will look at these changes if necessary. Then everyone signs the contract and we then start scheduling migrations and getting even more detail on the libraries being migrated.

THINKING BIG
A resource-sharing consortium is a different entity from individual libraries. That is obvious, of course. The most obvious change is to go from separate, information “silos” of individual libraries to a larger entity with more resources for the various libraries’ users. Library users like to have access to the longer tail and they have taken to these consortia every time they get the chance. In the Google era, many of our users are used to more access to information with fewer walls between information sources.

It is new, yes, however, thinking about the implications of these kinds of networks is lagging in the field. The scale of Evergreen is enormous and enormous is not 10 times a small library or 100 times a small library but a new thing. There are implications to this fact—for instance, the Evergreen Superconsortium—and given that we have had more experience with moving libraries to this new world, we can help you understand these implications in your environment.

Thanks to Jason Etheridge, Sally Fortin, Galen Charlton, and Jonathan Seitz for comments and helpful suggestions. Errors are, of course, mine.

Bob Molyneux
June 9, 2010

Licensed under Creative Commons Attribution-Share Alike.

June 10, 2010

Bookmark to: