Cover Story

2004: Year of the University Press

Features

Library Materials from "Anywhere"

SUNYConnect Advances

SUNY Albany Part of... ALEPH

SUNYAUG 2004

Welcome Ben and Nathan

Additional SUNYConnect Updates

How to Contact Us

Linkable Links

Photo Gallery

Link to the SUNYConnect Committees List

ALEPH sites overall have a great variety of models for the conversion and implementation of the system as well as living with it going forward. During the spring of 2003, we appointed an Ex Libris Implementation Task Force consisting of representatives from all functional areas of our three libraries, our campus Oracle DBA and his backup. The group has evolved and now includes 16 people including management and operational personnel and systems/IT professionals. We met regularly and identified goals and preparatory projects in advance of implementation. Brenda Hazard, Head of Media, Microforms, Periodicals and Reserve, and I serve as co-chairs. This has worked well as a means of keeping the work of the task force moving forward, although at times the size of the group made it difficult to focus on specific problems and to engage the entire group. Working groups were established, each chaired by a task force member, to focus on specific functions, such as circulation or acquisitions. Membership on the working groups was not limited to persons on the task force. The long-standing Online Public Interface Committee has representatives on the task force and serves as the working group for the OPAC. The goal was to involve as many library staff members early in the process as possible. The working groups manage the tables for their areas.

During the summer of 2003, Noam Kaminer of Ex Libris Israel conducted a "kick off meeting" and soon after that our project manager, Michael Ben Ami, also of the Israel office, spent several days with us conducting the system analysis and providing much guidance as we started the long road to conversion. It also began a year long relationship with Noam and Michael and to a lesser extent others in the Israel office. We communicated frequently by email. Michael worked directly on our server from Israel. It was a method of working that could not have happened ten years ago when we last upgraded our system.

As STP approached, the task force had weekly phone calls with Michael and Noam to focus on specific questions and problems. This was very helpful in getting them to respond quickly to our problems.

We spent many months of preparation reading documentation and exploring version 14.2 in order to gain some familiarity with the system. This was the case, even though we knew that we would convert to version 16 of ALEPH. Ex Libris provided early iterations of v.16 training in the set-up and use of the system and its modules. This training was then amplified within the working groups.

We purchased two Sun Fire V880 servers as test and production servers, each with 4 900MHz processors, 8GB (gigabytes) of memory, and six 73GB internal disks. We gave the production server 6 processors and 12GB of memory, which left the test server with 2 processors and 4GB. Later, we found that the test server was too slow, so we purchased two more re-manufactured 900Mhz processors and 4GB of memory for it.

For primary storage, we purchased Dell 3510 StorEdge fiber channel disk arrays that are managed as a single entity and dual-connected to each server. Later, for automated disk-to-disk backups, we added another array of disks. With a database of 1.3 million bibliographic records, 790,000 full authority records, and 2 million items, the Oracle data, ALEPH tables and programs (not including operating system and temporary storage) utilize approximately 164GB out of 315GB allocated. Rebuilding our word indexes (p-manage-01) takes approximately 22 hours.

Our implementation was scheduled for a time of major upgrades to ALEPH and we felt buffeted by constant changes. We felt that we were doing beta, or even alpha, testing of version 16. Our database was first loaded on version 16.01 in January 2004 and then moved to 16.02 in March 2004 at the same time as the second test conversion.

The publication pattern file was not delivered as promptly as we wished. Rather than continuing to wait for it, we should have done more creation of publication patterns for practice. The file of ALEPH-generated patterns brought with it idiosyncrasies from other sites: problems with the $3 (active date) and $9 (connection with the subscription). Better preparation on our part would have permitted us to make better use of the file when it was received.

We planned to migrate during the summer of 2004 ever since the SUNYConnect initiative began in order to coincide with the expiration of our contract with Geac, provider of our ADVANCE system. We had no urgent need to migrate because ADVANCE was stable and serviceable and staff were familiar with it. The new system does not offer compelling advantages over ADVANCE, but there are some appealing features.

We liked having the flexibility to name the online catalog and create an original logo. (See Minerva.albany.edu ). Logical bases have helped us provide better access to certain elusive groups of materials, such as dissertations.

We are looking forward to exploring ALEPH's capability to broaden our electronic communication with ours users by sending email alerts and notices. The ability to customize almost every aspect of the system, from staff side to user side, is both exciting and overwhelming. One of the most attractive features of the SUNYConnect LMS is the promise of a SUNY-wide union catalog and universal borrowing. We are looking forward to that very much.

What would we wish to be different? A programmer who converted much of the data would "not have taken the data definitions so literally, " but would have experimented to see first hand what was happening to data. Library Systems staff were able to view the ADVANCE source code, but cannot do so for ALEPH. This is a handicap. Some task force members would have preferred 18 months or two years lead time instead of one year, while others feel that the tighter schedule was beneficial and more time would not have saved us from some of the problems we experienced. Some would have preferred phone calls with Ex Libris earlier in the process. It would have been helpful if the OPAC had been tested by a wider range of people than it was. Greater understanding of the system sooner would have been extremely helpful, but how that could be achieved is an open question. As with just about anything, if we were to repeat the process, we could do it better.

Advice for others? The documentation is somewhat scattered, but it is good. Thoroughly understanding the Web Guide and other materials on the Documentation Portal for the version you will be using is critical. Everyone should read the System Librarian and Services sections of each portion of the Guide. Likewise, the Database Management Guide is a gold mine of information. The tables are critical and understanding and building them early on is essential, but the programs and utilities must be understood also if the system is to run well. Insisting on this kind of homework will reduce floundering and the asking of questions whose answers are at hand. Make sure everyone involved understands what "systematic" means - as in "systematic testing" of a data load. Spot checking is not sufficient! Truly understanding the degree to which this system is integrated sometimes must be learned by experience. An apparently minor change in a table can have far reaching consequences, as can actions within the modules. Departments cannot set up tables in isolation, but must consider the effects of their choices on the work of other departments and the OPAC.

This project consumed huge amounts of time from a shrinking staff already doing full time jobs. At times the workload was overwhelming. The fact that we STP'd on time, have had no significant down time, and have had few complaints all indicate that the project has been successful.

It certainly is not over. We have yet to regularize the running of some programs, have not achieved regular warm backup, do not regularly synch the test and production servers, have not yet worked the last kinks out of some logical bases, nor have we mastered holds and recalls or email circulation notices. We do keep crossing various hurdles and have just recently gained some understanding of the UE_08 process (for authority control) and have firmed up permissions. The Online Public Interface Committee is still working on customizing the OPAC displays. This group has looked extensively at other ALEPH OPACs and has found that process helpful.

And then there are the service packs. As of this writing, Ex Libris has issued 500 service pack items for version 16.02. These require installation in test mode, testing, installation in production, decisions on optional items, and in some cases updating and distribution of PC files, not to mention keeping tracking of what has been done. Some items introduce their own problems. We are still coming to grips with methodology for and tracking of the updating of tables. We are just beginning to participate in the larger ALEPH world by requesting and sharing knowledge and experience and submitting PRBs. We still sometimes feel that we are being swept along faster than we can run.

Our group name may need changing since "Implementation Task Force" implies a finite project. It seems clear now that implementation will never be totally complete. We won't be finished with our initial implementation before the next release comes along! The system is clearly a "tool kit," not a finished system, and we foresee working and maximizing those tools as long as we are using ALEPH.

Overall, we are happy with the approach we took. Wide involvement of staff has allowed individuals to blossom, to learn and grow and contribute to the Libraries in ways that would not have been possible otherwise. Our Library Systems staff is too small and the system too massively complex and interrelated to have expected Systems to simply "do it all." Those intimately involved in the daily work are the most able to determine how best to set up tables to make the system serve their needs. Working with Michael and Noam was, for me at least, a rewarding foray into the global economy.

(Editor's note: Heather's article highlights similiarities and differences between "standalone" implementations of the SUNYConnect LMS and those on "shared servers". In addition, it points out the great benefits in having another SUNY university center as part of the SUNYConnect/ALEPH community. We are already seeing payoffs of Albany' greater participation in this community. Thanks Albany for all of your efforts!)