By definition, an Integrated Library Management System incorporates and affects all aspects of library activity. At Yale, the Library Systems Office is chiefly responsible for assuring the smooth and effective interaction of technology, both hardware and software, with the daily operation of other library units. In evaluating potential new systems, four specific subtopics determine how well a system can ultimately be supported.


Systems Architecture

A system architecture is the manner in which the components of a computer or computer system are organized and integrated. This environment defines what is possible for a system to do, and how a given task may be decomposed into subcomponents.

Systems Development

A system development environment determines how the system can adapt and grow over time. It includes both the initial vendor environment as well as the local environment, and potential interconnection and with third party and public domain environments.

Systems Security

The systems security environment determines how resources and information can be protected from unauthorized use, and how authorization, authentication, and access control policies are defined and implemented.

Systems Operations

The systems operations environment describes the interfaces and tools provided for daily execution of system tasks, ongoing maintenance and support. Operations include network and client tools and interfaces as well as central server support in performance of a practical work or involving the practical application of principles or processes.

The following sections expand and illustrate Yale specific criteria in each of these systems environments. A checklist documents the external attributes that measure compliance.



The system must have a multi-tiered Client/Server Architecture. Typically specific layers will implement Presentation logic and services (L1), Application logic (L2), and Data logic and services (L3). It is highly desirable that each layer be implemented in such a way that it can be installed on a platform selected, scaled, and managed independently from every other layer. Within L1 it is essential that the system have a windows client, a browser client, and a text (Z39.50 compliant) interface. In addition clients used to access the system should be easy to install, maintain, few in number, and be able to run in either a Windows or Macintosh environment. Ideally a client should be available also as a thin client that could run on a Solaris Sun Ray type of device or Linux workstation. At L2 it is highly desirable that servers can be distributed across multiple machines; it would be nice if the system architecture also allowed these servers to run in a cross platform environment. At L3 it is essential that the data be stored in a RDBMS or an ODBMS. ODBMS may be preferable to RDBMS since the storage of data in a variety of formats (i.e. audio, image, text, video) as objects would be more efficient and easier to manipulate. The RDBMS / ODBMS used should not be proprietary. i.e. it should use a sql92-compatible engine such as oracle/sybase/db2/postgresql/etc., not a custom-developed system from the vendor. In either case it is highly desirable if not essential that the system architecture allow for direct access to the database using ODBC software. At all levels, the system must also have API interfaces such that the data is addressable via a variety of programming languages that must include JAVA, C, and C++. Also at all levels the system should provide for multiple national languages through implementation of ISO standard 10646 (UNICODE). In addition, the system should provide tools for an X12 interface to EDI and ISO 10160/10161 protocols for ILL. Support for standards such as x12/iso 1016*/ldap/z39.50 would ideally be provided by vendor-implemented components in strict compliance with common use of those standards or by integration of reputable third-party components. Finally the architecture must be scalable and allow for the easy elimination of obsolete technology and the simple integration of new technology.



The system must provide a flexible development environment by providing APIs or source code to facilitate integration of: locally developed applications; third party software; web-based electronic resources; data exchange with external systems such as acquisitions vendors and bibliographic utilities; and interoperability with other Yale systems.

The cornerstone of a robust development environment for the library is the development environment of the vendor. It should consist of a minimal effective set of modern and current programming languages, operating systems, network and database interfaces, supported by industry standard tools to monitor and control change. The ability to demonstrate quality control as defined by ISO 9000 is mandatory, although certification per se is not. The development environment should accommodate short development cycles and continuous improvement, without the need for periodic wholesale upgrades to remain current. Any software content consisting of object code only, or developed using non-industry standard programming languages is unacceptable. Multiple development languages within a single component is undesirable except in the context of a clearly defined short term migration effort. The ability to import and export source code from customer and third party sites (with version control) is highly desirable. The ability to extend or implement common class libraries and interfaces (Java and C++) is highly desirable.

The primary software development tools for the library itself are C, Java, and Visual Basic, with the intent to emphasize C++ and Java in the future. The new LMS should provide for easy interchange of data and control with local routines created by these tools. Likewise the future LMS must support data access via standard, non-proprietary database and network protocols. ODBC, FTP and HTTP are mandatory. XML, XHTML, and MIME, are highly desirable. JDBC, CORBA, and IIOP are desirable.

More broadly, the library develops and customizes Web services based on integrated development environments (IDE) provided by IBM, Sun, Microsoft and others, as well as integrating and developing functions developed by others in the open software environment including, but not limited to Apache, CGI and Perl. While none of these environments is mandatory for the successful integration of LMS function with web function, scripting interfaces which work well in the open software environment are highly desirable. LMS access via the JVM applet and JNI environments are also highly desirable. Enterprise Java Bean (EJB) development environments are desirable.

An active user community, supported by the vendor is essential to the growth of new function, and incorporation of new technologies. Provision of tools / venues / websites for the development and exchange of user developed software is highly desirable.



SSL and LDAP are key components of a Public Key Infrastructure (PKI) which uses digital certificates for secure authentication and authorization (A&A) of electronic information over the network or Web. This form of A&A is preferable to traditional methods of restricting access to information based upon IP address or username and passwords. Restriction by IP address does not accommodate remote access and user names and passwords without SSL sends the data in the clear, which is an obvious security breach. Therefore, all systems, at a minimum, must be able to run a secure web server or SSL. The web server should also come from a well known vendor, implementing currently approved W3C and IETF protocols. Clients that are used to access technical services modules must also be secure in that private data must be sent encrypted over the network. Ideally the system should provide some form of API into each of the three components of a public key infrastructure:

  1. Certificate Authority, the issuer of digital certificates
  2. LDAP Server (i.e. an authentication database) and
  3. Attribute Server which contains decision making information not found in the certificate.



The four keywords are Reliability, Availability, Serviceability, and Redundancy. Old legacy mainframe systems are known for their reliability and it is highly desirable that any new system be as reliable as old NOTIS. NOTIS never failed as a result of an operating system or CICS problem. Thus its reliability is better then 99.99% (less than 50 minutes total unplanned downtime per year). It is highly desirable for us to obtain data either from the vendor or customer sites on unscheduled system down time. NOTIS is available nearly 24x7x365 and it is highly desirable if not essential for the new system to also be 24x7x365. We should not have to go down to rebuild tables or indices. In addition, batch processing of data should also be possible while the system is operational. When there is a problem with either the application or the operating system(s) it is essential that all vendors involved will be able to respond to problems and outages within a one hour notice. Service to the application should be as uncomplicated as possible and it would be highly desirable if service could be applied without taking the application down. The vendor should have established procedures to report application problems, distribute bug fixes, and release updates and new versions of the application. Ideally the system should conform to SNMP standards for remote problem determination, monitoring, and operation. The same standards should be applied to the operating system. Redundancy is essential in the new age of client server and has become the de facto standard at Yale for mission critical financial applications. The library should meet this standard. It is highly desirable for the new system to have the capability to update a production and backup system simultaneously without significant performance degradation. If this is not possible, vendors should provide or suggest alternate methods for Yale to run redundant systems.

At the application level customization and maintenance tasks should be graphically based and should not require a systems person to perform. Ideally the vendor will provide a browser interface into all modules and a universal client that can access all modules simultaneously.



Table 1 (summary)

Criteria Category


Highly Desirable




Windows, Browser, Text clients


Standard WWW clients and servers


Platform independent

Multi Processor

Industry Standard

X12 based EDI

ISO 1016x based ILL


Thin client

Cross platform

OO interface


User Access to Source code

ISO 9000 conformance

Version Control

ANSI C / C++ / Java

Control and Data interchange


Short cycles

Incremental change

IDE Code interchange

Class extensions


Apache, CGI, JVM, JNI

Single language per component

Enterprise Java Beans

ISO 9000 certificate




Staff mode encryption

B2 system security



SSH (for maintainence)


Attribute Server


99.99% uptime

24x7x365 operation

1 hour urgent response

Redundant operation option

Availability history

Live update / upgrade

Online indexing

Online reporting

Graphical customization interfaces

Universal client



Table 2 Architecture Detail


Table 3 Development Detail


Table 4 Security Detail


Table 5 Operations Detail


Last updated 7/5/00

By Systems Criteria WG