The technology of change: what's involved and how it is accomplished.
The process of changing or significantly upgrading automated library systems is referred to as "migration." In considering a major system change or upgrade, librarians must examine their options from several perspectives. Some of the major technologic issues which must be considered follow.
Why Change or Upgrade a System
The cost of migrating to a new ILS or significantly upgrading an existing system can be major so that a number of factors must usually coalesce to force a library to consider change. Factors which often play significant roles in this from a technological perspective include:
1. Is the computer hardware platform adequate for growth in terms of ports needed, disk storage, central processing unit (CPU) power, and the ability to add needed peripherals?
2. Is the hardware platform still being manufactured and maintained by its producer or the ILS vendor acting as a value added reseller (VAR)? Is servicing and maintenance adequate for the hardware and software?
3. Is the ILS software being adequately enhanced or supported by the vendor?
4. Are there major unresolved software bugs, missing capabilities never delivered, or other system enhancements which have never materialized?
Aside from frustration or limitations with an existing ILS, there may be a host of other political, economic, or functional reasons for migration. Purely from a technical perspective, however, several issues must be examined when considering a new system.
1. Integrated library systems are online transaction processing systems and a hardware platform which is optimized for this type of computer operation will give improved performance. CPUs which can be enlarged or added-to on a modular basis without having to trash existing equipment are desirable.
2. Libraries also demand a high level of reliability in terms of "up-time" as well as the integrity of the storage of data. Reliability and "up-time" issues will be a function of the hardware platform, software design, and operational issues. Many hardware platforms offer the ability to "mirror" (or shadow) databases which means that if a disk drive malfunctions the system will continue to operate. Fault-tolerant design in the hardware is also desirable. Certainly, reliability of any ILS must be examined on a similar sized system used by other institutions.
3. The importance of connectivity in ILSs are key in today's world. Does the ILS have compatibility with X.25, TCP/IP or OSI networking protocols? Can the ILS network or gateway with other computers in an institution, with national data highways such as Internet, or with other types of library systems?
4. High levels of performance and fast response time based on the experiences of similarly sized systems is crucial.
5. Costs for the hardware, software, and maintenance must be evaluated.
6. The ability to load multiple databases is becoming more important. This may include: locally defined files, indexing/abstracting services, full-text, directory information. Who will develop the tape loading programs if such a feature is available?
7. Flexible search software which is menu-driven for novices and command-driven for experienced users is important. Other features which must be examined include:
* keyword indexing;
* Boolean features;
* the ability to limit searches;
* multi-lingual access;
* user-generated document delivery;
* authority control;
* other related functionalities.
Once the decision has been made to migrate to a new ILS, the planning and implementation for the move are vital to the success of the project. A host of issues will have to be considered in the migration, many of which will arise depending on which system is chosen, who is doing the work, where the computer is located in an organization, and whether it is dedicated to the library application or not. Some issues include:
1. How will the data from the previous system be brought to the new system? One has to deal with bibliographic records, item records, patron records, transaction data, display records, and other related records which may exist depending on the functionality support in a system (e.g., circulation, OPAC, maintenance, serials, acquisitions, e-mail). Will the new system vendor do the programming to move the data? If so, will the old vendor share the file structures? Some vendors will NOT allow others to touch their data (or share file structures) which means that the migrating library is at the mercy of the original vendor.
2. What about the new hardware platform? Will the computer be dedicated to the library application? Will the computer reside in the library or some other central computing site of an organization. If it does not reside in the library, what restrictions are placed on the library's or vendor's access to the machine?
3. Once the hardware platform is in place, how long will it take to extract the data from the old system, reformat it for the new system, create all the appropriate indexes, debug the process, and test the results? Has the new vendor worked with the migration from the one a library is leaving?
4. How much down-time can be afforded by the library? What can be done to minimize this problem?
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||automated library systems|
|Date:||Jul 1, 1990|
|Previous Article:||Telebase signs ItalCable to global network agreement.|
|Next Article:||The implementation of change: planning and the RFP process.|