By definition, an Integrated Library Management System incorporates and effects all aspects of library activity. The smooth and effective interaction of technology, both hardware and software, with the daily operation of other library units is essential. In evaluating potential new systems, four subtopics determine how well a system can ultimately be supported.
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.
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.
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 with third party and public domain environments.
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.
The following sections expand and illustrate Yale specific criteria in each of these systems environments. A separate MSExcel checklist of Systems Criteria documents the external attributes which 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 essential 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 also be available for a Linux workstation and as a thin client. At L2 it is important that servers can be distributed across multiple machines; it would be advantageous 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 important, 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. This architecture should demonstrate and enable a quality approach to software products and services as specified in ISO guideline ISO-9000-3
The four keywords are Reliability, Availability, Serviceability, and Redundancy. Mainframe systems are known for their reliability and it is important that any new system be as reliable as NOTIS. NOTIS never failed as a result of an operating system or CICS problem. Its reliability is better then 99.99% (less than 50 minutes total unplanned downtime per year). NOTIS is available nearly 24x7x365 and it is essential for the new system to also be 24x7x365. The system 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. The system should regularly provide reports on the status of all system management and policy files, as well as all profiles, tables, and other parameters that control the system. When there is a problem with either the application or the operating system(s) it is essential that the vendor respond to problems and outages within one hour. 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 and documented procedures to report application problems, distribute bug fixes, and release updates and new versions of the application as specified in ISO guideline ISO-9000-3.
The Library system is, and will continue to be closely integrated with other University systems. As a result, it must conform to most standards established for University wide support. 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. Servers must operate on systems provided by either IBM or Sun, and clients must run on Intel platforms with Windows NT and Windows 2000 software. 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 system should meet this standard. It is important 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. Ideally the vendor will provide a browser interface into all modules and a universal client that can access all modules simultaneously.
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 important, and certification per se is desirable. 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 important. The ability to extend or implement common class libraries and interfaces (Java and C++) is important.
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 essential. XML, XHTML, and MIME, are important. 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 important. LMS access via the JVM applet and JNI environments are also important. Enterprise Java Bean (EJB) development environments are desirable.
An active user community supported by the vendor is essential to the growth of new functionality and the incorporation of new technologies. Provision of tools / venues / websites for the development and exchange of user developed software is important.
The operating system, and core application components must be designed to meet United States Trusted Computer Security Evaluation Criteria (TCSEC) level C2. Components of the system which build upon commercial products which have been C2 certified (e.g. DBMS) must not corrupt or bypass the security features of those trusted components. University security is based on Kerberos, SSL and LDAP as 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. 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 the 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.
Table 1 (summary)
Criteria Category Essential Important Desirable
Windows, Web, Z39.50 access
Standard WWW clients and servers
Scalable Platform independent
X12 based EDI
ISO 1016x based ILL
ISO 10646 UNICODE Thin client
Operations 99.99% uptime
1 hour urgent response
Redundant operation option
ISO 9000 report procedures
Maximum transaction 3 sec.
University supported platforms Availability history
Live update / upgrade
Easy client install
Graphical customization interfaces Universal client
Typical trans < .5 sec
Open system platform
Fast client initialization
Development User Access to Source code
ISO 9000 Quality Control
ANSI C / C++ / Java
Control and Data interchange
ODBC, FTP, HTTP access Short cycles
IDE Code interchange
Apache, CGI, JVM, JNI Single language per component
Enterprise Java Beans
ISO 9000 certificate
JDBC, CORBA, IIOP
Security SSL via WWW
Staff mode encryption
TCSEC level C2 design
Individual accountability Multiple authentication
SSH2 (for maintenance) API for PKI, LDAP
TCSEC C2 certified
ISO Guidelines for development of quality software products:
DoD Evaluation Criteria for Trusted Computer Systems (level C2)