Whenever you implement a complicated computer system for a complex institution, decisions and compromises have to be made. Ideally, you adapt the system to suit to the institution, but sometimes you have to adapt your institution's policies and practices to work with the system.

The decisions you make are based on the capabilities and limitations of the system, and sometimes the need to work around a system's shortcomings leads you to make certain fundamental decisions that are hard to reverse. Over time, the system vendors may address these shortcomings and add new features. But those original decisions may make it hard to take advantage of those improvements. Being an early adopter of a relatively new system could have far-reaching consequences for the functionality of the system.

When the multi-campus University of Hawaii was implementing the Voyager system in 2000, we had to decide whether to combine the catalogs of the individual libraries into a single database, or to set up separate databases for each library. Back then, Voyager wasn't particularly good at showing the holdings of an individual library in the single database model, and wasn't particularly good at showing a combined systemwide catalog from separate databases. For various reasons, the decision was made to go with a single database. Improvements in Voyager over the years have made it a lot better at making a system based on separate databases work seamlessly as a single system. If we were to make the decision today, we might choose the other option. But to switch over at this point would be very complicated and expensive.

Back to the top level page.
Rev. Aug. 15, 2004