Art Libraries Society of North America 31st Annual Conference
Wyndham Baltimore Inner Harbor, Baltimore, Maryland - March 20-26, 2003  

Session 3

Offsite, Out of Mind: Automating with ASP

Moderator:

Claudia Covert, Library Director, Corcoran College of Art and Design 

Speakers:
Linda Tompkins-Baldwin, Librarian, Baltimore Museum of Art
Marjorie Chenoweth, Library Director, Decker Library, Maryland Institute College of Art
Tom Rogers, SIRSI (DC Metropolitan Area Special Libraries)  

Recorder:
Alice Maggio

Claudia Covert introduced the speakers and began the session with an introduction to ASPs. An ASP, or Application Service Provider, refers to companies that lease software, accessible via the Internet, to remote sites, and customers may pay on an annual or per-use basis. The popularity of ASPs has been growing, and libraries are not the only ones using them. Organizations such as transit authorities, universities, and the healthcare industry have also found the ASP model attractive because it does not place additional strain on the staff, leaving them more time for work instead of maintenance. Some of the problems of ASPs, however, are the loss of control of records, the need to train staff, and complete dependence on the Internet and vendor for access. When considering ASP service, it is important to ask the vendor where the service is hosted, how often the software is upgraded, what kind of support is provided, who owns the data, and what recourse is available if the vendor declares bankruptcy. Covert stated that the Corcoran library decided to use an ASP when they needed to automate to meet accreditation requirements, and the institution was attracted to the low upfront cost of the service. Although the ASP allows little customization, and when problems occur it is often difficult to determine if it is an IT issue or a vendor problem, the library, the administration and the IT department are very happy with the ASP.

Linda Tompkins-Baldwin explained that the library at the Baltimore Museum of Art began to consider an ASP when a consortium project for automation with Johns Hopkins University did not come to pass. The museum did not have the hardware, personnel or financial resources to support a stand-alone system so the ASP was an attractive option. Other positive features included the fact that the vendor supports system changes, and an ASP did not require the library staff to perform backups or daily maintenance. Tompkins-Baldwin stressed, however, that because an ASP is accessed via the Internet, the system is only as good as one’s Internet service provider. The library experienced some connectivity issues after automating but subsequently changed Internet providers. Some of the additional problems they experienced included changing URLs, system failures due to inadequate memory, and initial lack of support for ASP customers, but she noted that all of these issues were resolved quickly. Overall, they are very happy with ASP service. She noted that the pricing structure is comparable to annual service charges for most stand-alone systems, and there is less financial risk because the library did not purchase a system upfront.

Marjorie Chenoweth then described the three-stage automation process at the Maryland Institute College of Art. The Decker Library first automated in 1984 when consultants recommended they install a turnkey microcomputer-based system. The library was not involved in the selection decision, and the college purchased a software package that was being used by only one other library. Consequently, the system was not well supported either by the vendor or the college tech department. Between 1995 and 1996 they entered their second phase of automation when the library purchased a stand-alone system. Despite continuing support problems from the campus tech department due to high staff turnover, the stand-alone system worked well until the hard drive crashed in 1999. They then began to consider an ASP, which was attractive for several reasons. First, the only major upfront cost was a one-time data conversion charge. In addition, the library no longer needed to provide server space or store backup diskettes, and they were no longer dependent on the college tech department for support. The conversion to the ASP system went smoothly and corrected data load errors that had existed in the stand-alone system. Chenoweth ended by recommending ASPs for libraries with limited funds for automation, limited support from in-house tech departments, or where library technology needs may be a low priority.

Tom Rogers of SIRSI was the final speaker of the session. He began with a brief history of SIRSI as one of the top providers of integrated library systems and described some of the current client base. SIRSI developed their ASP product, SIRSI.net, when the technology matured enough to make it a viable system and customers began to ask for such a product. They thought at first the ASP would appeal to only small or medium-sized libraries with little technology support or knowledge, but SIRSI attracted several large clients. Though the ASP is web-based, the system has the same interface as their ILS and digital media archive products, and it runs on multiple servers housed in data centers in St. Louis, MO and Huntsville, IN. Data is backed up every day, and backup tapes are sent to a cold storage facility. The libraries, however, do retain ownership of their data. Rogers noted that Internet service providers are the Achilles heel of the ASP, but overall, ASP solutions allow the library staff to focus on library work without worrying about hardware, maintenance and other issues. He concluded by offering to answer specific questions after the session.

A question and answer period followed during which Tom Rogers and the other panelists addressed questions relating to cost, data conversion and interoperability.

Claudia Covert ended the session by thanking the speakers.