20190614_LED_Requirements_final.docx

Specifications Web-Scale Library Services Platform (LSP) The Army University 14 June 2019 Part 1: General Information

1. Overview. This is a non-personal supply contract to provide an UNCLASSIFIED turnkey cloud-based, web-scale Library Service Platform (LSP) that is commercial off-the-shelf (COTS) for a consortium comprised of thirteen member libraries (with the potential to expand to sixteen libraries) and an administration and management office geographically dispersed across the Continental United States. The LSP will be composed of an Integrated Library System (ILS), a web-scale index-based Discovery Tool, an authentication layer, and electronic resource management tool (ERM).

1.1. Description of work/Introduction. The Contractor shall provide all personnel, equipment, supplies, facilities, transportation, tools, materials, supervision, and other items and non-personnel services necessary to perform Library Services Platform Hosted Service as defined in this Statement of Work except for those items specified as government furnished property and services. The Contractor shall perform to the standards in this contract.

1.2. Background. In 2016, U.S. Army Training and Doctrine Command (TRADOC) reorganized Army professional military education under a single university-type system called Army University to increase academic rigor, create greater opportunities for accreditation, and enhance the quality of the force. Army University is aligning Officer, Warrant Officer, Non-Commissioned Officer and Department of the Army Civilian education Systems across TRADOC under this single academic structure. The TRADOC academic libraries support the schools and Centers of Excellence (CoE) that make-up Army University. In October 2016, the Army Learning Coordination Council (ALCC) approved a plan to create the Army University Library Enterprise System (AULES) with the intent to improve findability and accessibility of academic library resources across the Total Force, combine like administrative and operational library processes, and provide the ability for library staffs to work collaboratively to license, manage, discover, use, share and preserve print and electronic collections across Army University libraries. The LSP concept is to combine 13 stand-alone libraries into a unified Library Service Platform that will have a single, shared system environment that will enable Army University to enable and improve rigorous and relevant learning and to maintain its Department of Defense (DOD) and academic accreditations. As a consortium, the libraries will function collectively as the Army University Library Enterprise System while continuing to maintain individuality and autonomy to provide unique support to their associated schools/CoEs.

The LSP is to centralize operations for the TRADOC libraries. The goal at this time is to allow for the centralized search of all the resources of the TRADOC libraries as well as the ability to search each library individually. Patron databases are expected to be shared with role based permissions. Bibliographic records are expected to be shared with local customization allowed. Circulation rules, including lending policies, are expected to have a shared general vocabulary, with base rules with local libraries being able to customize as needed. Libraries are all run independently, with a staff of 4 at Army University facilitating an enterprise level solution, with cooperative centralization of some tasks.

Specific details on staff size, patron base, collection breakdown, and database/ eResource subscription numbers can be found in Appendix A. The same information for optional future expansion sites can be found in Appendix B. Current migration timeline can be found in Appendix C. Government Peripheral Equipment List can be found in Appendix D. Additional Information about current library’s setup can be found in Appendix E. Primary and Secondary Library Resources can be found in Appendix F.

1.3. Requirements. TRADOC/ArmyU requires a fully operational, UNCLASSIFIED, turnkey cloud-based web- scale Integrated Library Service Platform (LSP). The winning Contractor shall provide an Integrated Library Service Platform (LSP) that incorporates and shares information across the following functional areas within the consortium: Integrated Library System (ILS), a web-scale index-based Discovery Tool, an electronic resource management tool (ERM), and authentication layer.

The base year(s) of the requirement will include a one-time implementation task (to include: project manager; project plan with milestones; installation, configuration, single sign-on authentication layer with a wild card SSL for remote database access, staff training, and data migration costs for the 13 member libraries); and an annual subscription for the COTS ILS, Discovery, ERM, and authentication layer with 24/7 help desk, system maintenance and support including software updates and upgrades. The four option years, if exercised, will be for the annual subscription to the COTS LSP component license(s) with 24/7 help desk, system maintenance and support including software updates and upgrades.

This project will result in a single, shared implementation of the selected ILS software. The ILS shall be a Software as a Service (SaaS) system utilizing a fully cloud-based architecture that does not require the use of any locally installed vendor-client software on customer equipment and must meet the security requirements as identified in section 5.1 Server/Security. The ILS will operate in a consortium environment for public and staff use that is COTS.

This platform shall support core library operations to include: patron management; circulation; cataloging, online public discovery and access, acquisitions, serials control, collection analysis, course reserves, electronic resource and licensing management, and reporting. This project will result in a single, shared implementation of the selected ILS software. ILS must be able to fully integrate with a web-scale Discovery tool and Authentication service.

The central authentication service (CAS 2) layer must be provided by the winning vendor. The authentication layer must provide access to content within the ILS, and Discovery Tool. The discovery tool must integrate with existing data stores such as digital archival systems and content management systems. The Discovery must include a web portal capability with customizable GUI staff-end and a public-facing site. The Discovery Tool will require 14 iterations of the web-scale Discovery tool software (i.e., one each for the 13 libraries and one over-arching enterprise (ArmyU) layer with the capability to add up to three additional iterations as the consortium grows).

Vendor bids will include all required pieces of the LSP, as detailed above (ILS, Discovery Tool, electronic resource management tool (ERM) and Authentication Layer), to be considered. No partial quotes will be considered. Vendors should explain in their responses how their solution(s) would interact with other Vendor’s services such as web-scale index-based Discovery or Authentication system to provide the LSP concept. Vendors should explain in their responses how they would create the LSP that will support a consortium.

The platform must consistently provide the functional requirements, required features, and project deliverables described below. To improve student, faculty, and staff access across TRADOC to the combined resources of the Centers’ and Schools’ Libraries, the library services platform must feature a multitenant architecture, as well as a discovery tool that provides immediate access to both print and electronic resources.

All components of the LSP must be able to operate over both NIPR and Commercial networks provided by the ARMY. Once established, up to three additional Army libraries are projected to migrate to ArmyU Library Services Platform in the FY20-23 time-frame.

1.4. Scope. This contract includes a COTS Integrated Library System (ILS), a web-scale index-based Discovery tool, an electronic resource management tool (ERM), an authentication layer, and the services to manage the training, migration, application implementations and continued regular service maintenance.

1.5. Period of Performance. The period of performance shall be for one (1) Base Year and four (4) 12-month option years. The Period of Performance reads as follows:

1.6. General Information.

1.6.1. Recognized Holidays. All Federal Holidays

1.6.2. Hours of Operation. Contractor will have the platform available for access by government users and researchers 24 hours a day, 7 days a week, and 365 days a year with a 96% operational rate barring scheduled maintenance or emergencies IAW section 5.1 of this SOW. Scheduled maintenance must take place outside of normal library operating hours which are 0600 EST to 0100 EST daily, not including Federal Holidays.

1.6.3. Place of Performance. The work to be performed under this contract will be primarily performed at the Contractor’s facility except for scheduled training and site visits which will be conducted at the individual library locations during implementation.

1.6.4. Type of Contract. The government Intends to award a Firm Fixed Price Contract.

1.6.5. Security Requirements. N/A

1.6.6. Physical Security. The Contractor shall be responsible for safeguarding all government information stored off site during the course of the contract. (See para. 1.3)

1.6.7. Post Award Conference/Periodic Progress Meetings. The Contractor agrees to attend any post award conference convened by the contracting activity or contract administration office in accordance with Federal Acquisition Regulation Subpart 42.5. The contracting officer, Contracting Officers Representative (COR), and other Government personnel, as appropriate, should for the first meeting meet face-to-face and then meet periodically through a mixture of virtual and face to face meetings at the discretion of the Government with the Contractor to review the Contractor's performance. At these meetings the contracting officer will apprise the Contractor of how the government views the Contractor's performance and the Contractor will apprise the Government of problems, if any, being experienced. Appropriate action shall be taken to resolve outstanding issues. These meetings shall be at no additional cost to the government.

1.6.8. Key Personnel. The following personnel are considered key personnel by the government: The Contractor shall provide a contract manager who shall be responsible for the performance of the work. The name of this person and an alternate who shall act for the Contractor when the manager is absent shall be designated in writing to the contracting officer. The contract manager or alternate(s) shall have full authority to act for the Contractor on all contract matters relating to daily operation of this contract. The contract manager or alternate(s) shall be available between 8:00 a.m. to 4:30p.m. CST, Monday thru Friday except Federal holidays.

1.6.9. Data Portability. Three months prior to the termination of this contract, vendor agrees to facilitate the orderly and professional transfer of Government data stored by the vendor for this contract as required by the Government.

Part 2: Definitions and Acronyms

2. Definitions and Acronyms.

2.1. Definitions.

2.1.1. Contractor. A supplier or Contractor awarded a contract to provide specific supplies or service to the government. The term used in this contract refers to the prime.

2.1.2. Contracting Officer. A person with authority to enter into, administer, and or terminate contracts, and make related determinations and findings on behalf of the government. Note: The only individual who can legally bind the government.

2.1.3. Contracting Officer Representative (COR). An employee of the U.S. Government appointed by the contracting officer to administer the contract. Such appointment shall be in writing and shall state the scope of authority and limitations. This individual has authority to provide technical direction to the Contractor as long as that direction is within the scope of the contract, does not constitute a change, and has no funding implications. This individual does NOT have authority to change the terms and conditions of the contract.

2.1.4. Deliverable. Anything that can be physically delivered, but may include non-manufactured things such as meeting minutes or reports.

2.1.5. Discovery Service. Discovery Service Separate web-scale product that includes a prepopulated central index along with a scoped discovery result interface. An index-based discovery service returns vendor or library provided descriptive records with elements such as citation data, abstracts, and tables of contents. Once a record is selected, users click a link or button to access the full text of articles from the discovery's display results. These discovery services enable libraries to provide article-level results to their users.

2.1.6. Discovery Service Knowledgebase. The knowledgebase of the web-scale Discovery product is created and continuously updated by the Discovery Service vendor. Content managed within a knowledgebase generally includes the individual journal titles, libraries' e-content, and open access licenses and any additional relevant details, such as title or publisher changes through agreements with local libraries, publishers, and aggregators to receive their content to build and continuously update their centralized index.

2.1.7. Equipment. A tangible item that is functionally complete for its intended purpose, durable, nonexpendable, and needed for the performance of a contract. Equipment is not intended for sale, and does not ordinarily lose its identity or become a component part of another article when put into use. Equipment does not include material, real property, special test equipment or special tooling.

2.1.8. Government Furnished Property. Property in the possession of, or directly acquired by, the Government and subsequently furnished to the Contractor for performance of a contract. Government-furnished property includes, but is not limited to, spares and property furnished for repair, maintenance, overhaul, or modification. Government-furnished property also includes Contractor-acquired property if the Contractor-acquired property is a deliverable under a cost contract when accepted by the Government for continued use under the contract.

2.1.9. Government Property. All property owned or leased by the Government. Government property includes both Government-furnished property and Contractor-acquired property. Government property includes material, equipment, special tooling. Special test equipment, and real property. Government property does not include intellectual property and software.

2.1.10. International Association of Scientific, Technical and Medical Publishers. Leading global trade association for academic and professional publishers who each year collectively publish nearly 66% of all journal articles and tens of thousands of monographs and reference works.

2.1.11. Key Personnel. Contractor personnel that are evaluated in a source selection process and that may be required to be used in the performance of a contract by the Key Personnel listed in the SOW. When key personnel are used as an evaluation factor in best value procurement, a quote can be rejected if it does not have a firm commitment from the persons that are listed in the quote.

2.1.12. Loss of Government Property. Unintended, unforeseen or accidental loss, damage, or destruction of Government property that reduces the Government’s expected economic benefits of the property. Loss of Government property does not include occurrences such as purposeful destructive testing, obsolescence, normal wear and tear, or manufacturing defects. Loss of Government property includes, but is not limited to— 2.1.12.A. Items that cannot be found after a reasonable search.

2.1.12.B. Theft.

2.1.12.C. Damage resulting in unexpected harm to property requiring repair to restore the item to usable condition.

2.1.12.D. Destruction resulting from incidents that render the item useless for its intended purpose or beyond economical repair.

2.1.13. Material. Property that may be consumed or expended during the performance of a contract, component parts of a higher assembly, or items that lose their individual identity through incorporation into an end-item. Material does not include equipment, special tooling, and special test equipment or real property.

2.1.14. Physical Security. Actions that prevent the loss or damage of Government property.

2.1.15. Property. All tangible property, both real and personal.

2.1.16. Property Administrator. An authorized representative of the contracting officer appointed in accordance with agency procedures, responsible for administering the contract requirements and obligations relating to Government property in the possession of a Contractor.

2.1.17. Property Records. The records created and maintained by the Contractor in support of its stewardship responsibilities for the management of Government property.

2.1.18. Provide. The action of furnishing, as in Government-furnished property, or to acquiring, as in Contractor-acquired property.

2.1.19. Quality Assurance. The government procedures which verify that services being performed by the Contractor are performed according to acceptable standards.

2.1.20. Quality Control. All necessary measures taken by the Contractor to assure that the quality of an end product or service shall meet contract requirements.

2.1.21. Subcontractor. One that enters into a contract with a prime Contractor. The Government does not have privity of contract with the subcontractor.

2.1.22. Work Day. The number of hours per day the Contractor provides services in accordance with the contract.

2.1.23. Work Week. Monday through Friday, unless specified otherwise.

2.2. Acronyms.

Part 3: Government Furnished Property, Equipment, and Services

3. Government Furnished Items and Services

3.1. Services. The Government will provide an ArmyU POC to assist with each piece of the migration at each location, including facilitating entry to installations and help schedule the migration of existing digital information, databases, excel spreadsheet, and Integrated Library System data into the new system. Government will provide an additional POC for emergency data breaches, to be contacted in accordance with section 5.2 Server/Security.

3.2. Lost Government Property. N/A

3.3 Government Resources. Government currently maintains OCLC Cataloging subscriptions and WorldShare memberships for libraries. The Government will provide OCLC cataloging subscriptions and WorldShare memberships for all libraries. The Contractor will not need to provide the subscriptions or memberships. POCs for this are at each library. (See Appendix A for OCLC symbols) Part 4: Contractor-Furnished Items and Services

4. Contractor Furnished Items, Responsibilities and Deliverables.

4.1. General. The Contractor shall furnish all accesses, training, and facilitate the migration of existing government data into a cloud service. Contractor will provide an established Library Service Platform that integrates and shares information across the following functional areas: library core operations to include: patron management; circulation; cataloging; online public discovery and access; acquisitions; serials control; collection analysis; course reserves; electronic resource and licensing management; and reporting, collection management, archives, authentication and discovery layers.

4.1.1. Upon proposal the contractor shall provide the following:

4.1.1.A. Vendor must provide a list of three references similar in size and scope to Army University LSP consortia concept. References should be clients who have had their system installed (including ILS and Discovery) within the past 48 months. (Include name, contact, address, telephone, system(s) installed and date of installation, architecture of data storage and redundancy (for example, multi-tenancy, cloud distributed, etc.).

4.1.1.B. The platform’s ILS must provide proof of concept that it is hosted on a cloud as a SaaS.

4.1.1.C. The platform’s Integrated Library System (ILS) must provide proof of concept that access is a fully cloud-based architecture that does not require use of any locally-installed vendor-client software on government equipment.

4.1.1.D. Government currently utilizes these peripherals: Honeywell Voyager MS9520/MS9540; Honeywell Voyager 1400g; Honeywell Hyperon 1300G; PSC QuickScan 6000/6500; Tech Econwand IDT1230-U. System must identify if those listed will work with platform or provide a list of scanners that are compatible.

4.1.1.E. Government currently utilizes these RFID systems Envisionware and 3M Bibliotheca. Vendor must identify if those listed will work with platform or provide separate lists for the peripherals which are compatible with the LSP for self-checkout machines, PC reservation manager and RFID.

4.1.1.F. Vendor must provide a plan to support multiple layers of Access and Authentication to accommodate the various types of access and their required levels of protection (i.e. username password for general access, Two-Factor Authentication for more sensitive data/information, etc.)

4.1.1.G. Vendor shall provide a parent-child schematic for all LSP components.

4.1.1.H. Vendor must provide a copy of their cyber incident response plan.

4.1.1.I. Vendor must provide screen shots of how publisher’s cover art for materials including books and journals will display within the LSP by their provided enrichment service. (i.e. Syndetics) 4.1.1.J. Vendor project plan shall identify at a minimum the individual Center/School sequence of events (e.g., planning/training, migration, testing/remediation, and “go live”/remediation phases), and final enterprise-level testing/remediation. Government preferred migration timetable is listed in Appendix C. Any other proposed timeline must have all migration tasks and GO live dates completed 60 days before identified legacy system sunset dates.

4.1.1.K. Vendor must provide the following certificates:

4.1.1.K.1. Service Organization Control SOC 1 Type 2 and SOC 2 Type 2 certifications.

4.1.1.K.2. ISO 270001 security certification (Information Security Management) 4.1.1.K.3. NIST 800-53 SP-3 certification 4.1.1.K.4. ISO 27018:2014 certified (protection of PII in the cloud) 4.1.1.K.5. ISO 27017:2015 certified (Security controls for the cloud) 4.1.1.K.6. ISO 22301:2012 certified (business continuity management)

4.1.2. Upon award the contractor shall provide the following:

4.1.2.A. Vendor shall provide any password, access, and auditing policies that will be used to access the system and explain how those passwords are protected in the system upon time of award.

4.1.2.B. The platform’s central authentication service (CAS 2) layer must be provided by the winning vendor upon time of award.

4.1.2.C. The winning vendor must provide a wild card SSL certification for remote database access upon time of award.

4.1.2.D. The hosted solution shall provide protection at all security levels 1-4 Perimeter (see link below); (Operating systems and servers; Host Protection; Information Protection) including intrusion detection, reference DoD Cloud Computing Security Requirements Guide (https://iasecontent.disa.mil/cloud/SRG/index.html).

4.1.2.E. Vendor shall have security and access control mechanisms in place to secure government information. If any services are outsourced or managed by a 3rd party, policies on terminations, passwords and how access is granted must be provided to government systems by these 3rd parties at time of award.

4.1.2.F. The winning vendor must provide an enrichment service such as Syndetics at time of award to integrate with ILS and Discovery.

4.1.2.G. Vendor shall have a backup plan for ILS database(s). A copy of the backup plan will be provided at time of the award.

4.1.2.H. Vendor shall provide contact plan for Consortium POC and access to informational resources and FAQs at time of award.

4.1.2.I. Vendor shall provide access to basic 24/7 help desk support to mitigate and resolve problems quickly and accurately with minimum downtime (not to exceed 4% downtime during business hours on any given day without advance customer notice). Shall accept support requests that do not require contract modifications from any consortium member library and from consortium central staff.

4.1.2.J. Vendor shall provide screen shots of their library staff customer portal for accessing help documentation as well as describe how the interaction with the Vendor’s help desk and provide screen shots/video tutorial of trouble ticket system process.

4.1.2.K. At time of award, Vendor shall provide POC who will lead and manage the project plan, timeline, data migration, testing, and implementation phases.

4.1.2.L. At time of award, Vendor shall provide the government POC(s) with the emergency cyber incident response plan that is compliant as specified in 5.1 Server/Security.

4.1.2.M. After award but before migration, Vendor shall provide the government with necessary equipment to perform the inventory function, if specialized equipment is required. This property once installed will become Government Property and will remain in the Libraries even after contract expiration.

Part 5: Required Characteristics

5.1. Server/Security

5.1.1. The ILS SaaS cloud and software system shall meet one of the following conditions – 5.1.1.A. Must be FedRAMP authorized for the Moderate Impact security level; or 5.1.1.B. If the system is not FedRAMP authorized, the ILS provider shall demonstrate that it is actively working toward authorization by the fact that it is listed on the FedRAMP Marketplace website at https://www.fedramp.gov as either "Ready" or "In Process;" or 5.1.1.C. If the system is not FedRAMP authorized or found listed on the website above, the ILS provider shall demonstrate that the ILS is hosted on a FedRAMP authorized cloud. The cloud's name and the physical location of the servers shall be identified. The cloud's name shall be listed under "Authorized" on the website above. If the system is not FedRAMP authorized before the exercise of a new contract option period, the ILS provider shall provide evidence to the Contracting Officer that progress toward achieving FedRAMP authorization has been made since the time of award or the start of the option period.

5.1.2. The ILS vendor shall submit all supporting artifacts developed for their provisional Authorization to Operate (ATO) to the Contracting Officer’s Representative (COR) for submission to the TRADOC G6 for review. The ILS vendor, through the RMF process, shall obtain and maintain the appropriate Authority to Operate (ATO) IAW the data inventory of the application. The ILS vendor shall provide a report to the Government at the time of any change to the status of their ATO with a plan to mitigate/address. Upon the request of the Government, the ILS vendor shall provide technical documents for review.

5.1.3. System shall enforce authentication password requirements for users in accordance with Department of Army Pamphlet 25-2-13 para. 5-4i Exemptions: minimum of 14, two uppercase, 2 lowercase, two numbers, and two special characters.

5.1.4. Upon time of bid system must provide the following certificates:

5.1.4.A. Service Organization Control SOC 1 Type 2 and SOC 2 Type 2 certifications.

5.1.4.B. ISO 270001 security certification (Information Security Management) 5.1.4.C. NIST 800-53 SP-3 certification 5.1.4.D. ISO 27018:2014 certified (protection of PII in the cloud) 5.1.4.E. ISO 27017:2015 certified (Security controls for the cloud) 5.1.4.F. ISO 22301:2012 certified(business continuity management)

5.1.5. In the event of a cyber incident on the platform, the information system must generate audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event.

5.1.6. The Vendor shall provide their Cybersecurity and Information Assurance Incident Response Plan. The plan will include details pertaining to the management, mitigation and reporting of all security incidents. The data includes all analytical data such as the initial reporting, remediation, damage assessment and final reports pertaining to the incident.

5.1.7. Vendor shall provide the government POC(s) with the emergency cyber incident response plan that is compliant as specified in 5.1 Server/Security.

5.1.8. All data stored in Vendor’s systems remains the exclusive property of the Government and no copies of data shall be made by Vendor without explicit direction by authorized agents of the Government. In the event of a migration of the data to a new system, Vendor is required to maintain the data until successful migration is confirmed by the Government, up to a maximum of 180 days from end of contract.

5.1.9. The hosted solution shall demonstrate protection at all security levels 1-4 Perimeter (see link below); (Operating systems and servers; Host Protection; Information Protection) including intrusion detection, reference DoD Cloud Computing Security Requirements Guide (https://iasecontent.disa.mil/cloud/SRG/index.html).

5.1.10. Platform’s must operate on machines running current Microsoft Windows (64bit) Operating Systems or higher in an encrypted environment and provide support for one previous version of the OS.

5.1.11. Vendor must provide a protocol to document and rapidly assist customer with expunging from the cloud-based system any bibliographic record(s) and associated full-text content that is deemed to be un-releasable, subsequent to said item(s) having been placed into the cloud-based system (such “restricted spillage may cause significant harm to US national security interests). An automated content and/or document management application augmenting the vendor’s capabilities with an administrative management console for Library Staff’s access to configure application operations.

5.1.12. Vendor must require any patron accessing their system account information to go through a strongly encrypted authentication method to ensure minimal security risk (such as Secure Hypertext Transfer Protocol connection or HTTP over Secure Socket Layer).

5.1.13. Vendor must provide an automated method/application to scan content uploaded for classification markings or other content not authorized. The Method/Application will allow Administrators to Add/Modify/Remove content to be scanned against.

5.1.14. Vendor must provide ongoing library staff customer support to include system troubleshooting and application advice during normal hours of TRADOC operation by telephone, online, or in person.

5.1.15. Platform must utilize URL verification for bibliographic records and websites.

5.1.14. The platform shall have the ability to customize searches to the following criteria: title, item type, file format subject terms, author, and publication dates/range. System shall search all item types such as books, DVDs, CD-Audio, films, periodical articles, serial articles, photographs, archival materials, artifacts, etc.

5.1.15. Platform must be deployed and maintained in accordance with current DOD and industry standards, including:

5.1.15.A. Third party access to the environment must be vetted and monitored per company policy and access is immediately disabled once no longer needed or when access is determined to be inappropriately provisioned in accordance with third party or service provider agreements.

5.1.15.B. Platform must operate in a Family Educational Rights and Privacy Act of 1974 (FERPA)-compliant environment or a demonstrated equivalent.

5.1.15.C. Platform must provide encryption of data between server and client.

5.1.15.D. Platform must provide granularity of security options for library staff and faculty.

5.2 Systems/IT LSP Functionality.

5.2.1. The platform must provide fully cloud-based architecture and hosting that does not require use of any locally-installed vendor-client software on customer equipment.

5.2.2. The platform must have a fully cloud-based architecture that does not require the use of any locally installed vendor-client software on customer equipment and must meet the security requirements as identified in section 5.1 Server/Security.

5.2.3. The platform must be an in-production, cloud-based system providing core library operations in a consortium environment.

5.2.4. The platform and data shall be physically located and operated in the Continental United States.

5.2.5. The platform and data shall be managed and operated by U.S. Citizens or approved qualifying contractors and subcontractors.

5.2.6. The platform’s must demonstrate full redundancy for all critical components and at critical interfaces and demonstrate 96% uptime outside of emergencies.

5.2.7. During migration the vendor shall provide system consultation, workflow analysis and system training for TRADOC and Army University staff through a mixture of virtual and on-site for each location, with total visits not to exceed 20 in-person visits across the consortium. On-sites visits may be required for ATO/troubleshooting coordination.

5.2.8. The hosted solution must notify Government of any maintenance of LSP 2 business days prior to taking the system down for maintenance and any time the LSP has to be taken down during TRADOC normal operating hours. See TRADOC hours of operation in section 1.6.2. In case of emergencies the hosted solution must notify Government POC as soon as possible.

5.2.9. The platform must provide a means for authenticating all administrative users and systems that access the environment and data. Platform shall allow for the configuration of access capabilities and permissions for each back-end user based on user type, user group, and customization of permissions for discrete elements of the dataset.

5.2.10. The platform must provide a Responsive Web Design (RWD) to accommodate various device platforms support for various web browsers across multiple platforms (e.g., Windows, iOS, Android, others) for both Staff and end-users, specifically Internet Explorer and Edge, Mozilla Firefox, Chrome, and Safari and provide support for two earlier versions of listed browsers.

5.2.11. The platform must support continuous operation during the transition.

5.2.12. Vendor shall provide help screens and informational resources as a component of their system at time of award.

5.2.13. The platform shall provide library staff basic 24/7 help desk support to mitigate and resolve problems quickly and accurately with minimum downtime (not to exceed 4% downtime during business hours on any given day without advance customer notice). Shall accept support requests that do not require contract modifications) from any consortium member library and from consortium central staff.

5.2.14. The platform shall provide a library staff portal, including an online help desk, trouble ticket reporting and a “Frequently Asked Questions (FAQ’s)” section.

5.2.15. The platform must allow a single staff user to be in multiple modules at the same time.

5.2.16. The platform must support the ability to set password policy specifying: minimum length and require periodic changes.

5.2.17. The platform shall prevent the staff/patron user from signing on after invalid logons attempts. The system must provide an option for reset of password for both staff and patron access.

5.2.18. The platform shall require any patron accessing their system account information to go through a strongly encrypted authentication method to ensure minimal security risk (such as Secure Hypertext Transfer Protocol connection or HTTP over Secure Socket Layer).

5.2.19. The platform shall default to English and provide each User Account the capability to set individual preferences (i.e. display preferences, etc.…) to be maintained and applied at User Logon for any additional options.

5.2.20. The platform must support the ability to import and export various file types, including but not limited to, TXT, CSV, XML, MARCXML, PDF, Cdda, ISO PCM uncompressed WAV at 96 KHz/24-bit depth rate, MP3, MPEG2, MPEG4 H.264, JPEG2000, Uncompressed AVI, 4K DPX, DOC, PPT, TIF, WMV, GIF, PSD, and HTML.

5.2.21. The platform must support the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) and allow search engine harvesting and indexing.

5.2.22. The platform must provide ability to edit and customize MARC records and fields.

5.2.23. The platform must support holdings statements and display of both serial and non-serial multi-part items as defined in ANSI/NISO Z39.71.

5.2.24. The platform must support importing and exporting of bibliographic, holding and authority records in MARC 21 Format and future frameworks from OCLC Connexion®.

5.2.25. The platform must support non-roman scripts, e.g. Chinese, Japanese, Korean, Cyrillic and bidirectional script display (e.g. Arabic, Hebrew) and the uploading of foreign language bibliographic records in MARC and non-MARC formats.

5.2.26. The platform must support multiple classification schema and subject vocabularies including, but not limited to, Library of Congress Classification and Subject Headings, Dewey Decimal Classification, SuDoc classification numbers, local classification schema, National Library of Medicine Subject Headings, and LC Genre Form Terms. The platform must enable each library to operate under multiple schema that may differ at each location.

5.2.27. The platform must have the ability to import metadata from records such as MARC, EAD, MODS, METS, TEI, KBART, Dublin Core, etc.

5.2.28. The platform must have the capability to integrate library data (such as title lists, reserve lists) into the learning management systems (e.g. Blackboard, Sakai); as well as for the content management system ContentDM; and guide management systems SpringShare’s LibGuides.

5.2.29. The platform must provide ability for individual libraries to customize searches/scopes not available in one library but available in another consortial library such as searching journal titles, reference books, or new books and those displayed results must provide a Responsive Web Design (RWD).

5.2.30. The platform must provide ability for integrated and seamless user experience without the complication of detailed software coding APIs that free up bibliographic, authority, patron, and transactional data.

5.2.31. The platform must include a service that displays books and journals cover art similar to Syndetics as an example.

5.2.32. The platform must provide the ability to add customizable public notes to items within an ERM such as copyright restrictions, number of views left on limited eBooks etc.

5.2.33. The platform will provide each library the ability to brand interfaces at the local and consortium level.

5.2.34. The platform must be WCAG 2.0 Level A and Section 508 compliant.

5.2.35. The platform must have a link checker for both the ILS and Discovery.

5.2.36. The platform must have the ability to create unlimited number of records.

5.2.37. The platform’s ILS and Discovery must provide federated search capabilities for online public discovery and at a minimum access via:

5.2.37.A. Functional Requirements for Bibliographic Records (FRBR) 5.2.37.B. Faceted searching 5.2.37.C. Spelling and search suggestion 5.2.37.D. Z39.50

5.3. Reporting and Analytics

5.3.1. The platform’s Integrated Library System (ILS) must have the ability to tune reports to a granular level appropriate to each facet of the system including but not limited to: Circulation, Acquisitions, error reporting, and Cataloging.

5.3.2. The platform’s ILS must support SQL-based database reporting, non-SQL based database reporting, and supports metadata schemas with the option of simultaneous use of Dublin Core, EAD, AACR2 and RDA.

5.3.3. The platform must have a customizable advanced reports module which includes:

5.3.3.A. Templates for commonly used statistics.

5.3.3.B. Ability to run staff user action statistics, i.e. individual staff member work actions taken by multiple parameters, including date, type of action, type of material, function, etc.

5.3.3.C. Report generator which allows users to easily query the database by combinations of user-selected fields and criteria.

5.3.3.D. Ability to run variable date range reports.

5.3.3.E. Ability to Auto-run as well as scheduled reports.

5.3.3.F. Ability to tune reports in granular level appropriate to each facet of the system including but not limited to: Circulation, Acquisitions, error reporting, and Cataloging.

5.3.3.G. Ability to ingest and present usage statistics in accordance with ANSI/NISO Z39.93-2014, the Standardized Usage Statistics Harvesting Initiative (SUSHI) Protocol. It must also allow import or manual entry of usage statistics not harvestable via SUSHI, including Counter-compliant and non-compliant data.

5.3.3.H. Ability to present history data and support trends analysis.

5.3.3.I. Ability to provide analytics, including location of users, IP addresses, link-through to proprietary databases, bounce rate, number of visitors, browser, OS, mobile device, based on varied date ranges.

5.4. Integrated Library System (ILS)

5.4.1. The platform’s ILS must support core library operations to include: patron management; circulation; cataloging; online public discovery and access; acquisitions; serials control; collection analysis; course reserves; and reporting.

5.4.2. The platform’s ILS must allow for the Minimum of 200 simultaneous staff access points such as user licenses or “seats.”

5.4.3. The platform’s ILS must allow for daily data backups.

5.4.4. The platform’s ILS must support streamlined function windows. For example, the ability to check in, renew, and view a patron’s record without moving between different windows or renew and view a patron’s record without moving between different windows.

5.4.5. The platform’s ILS must have the ability for mobile inventory control in stacks with use of a laptop or mobile device.

5.4.6. The platform’s ILS must support self-service circulation workstations identified in Appendix D.

5.4.7. The platform’s ILS must be able to set up user groups for both staff and patrons with varying privilege levels and access modules.

5.4.8. The platform’s ILS must support a tool for printing spine labels.

5.4.9. The platform’s ILS must support both electro-magnetic and radio frequency identification (RFID) item security systems.

5.4.10. The platforms ILS must allow staff to change the due date for one or more items in checkout mode.

5.4.11. The platform’s ILS must have live URLs (from the 856 field) in the display.

5.4.12. The platform’s ILS must recognize natural language keyword searches, recognize abbreviations in controlled vocabulary, and recognize DACS, EAD, MARC, and BibFrame schemas simultaneously, while only displaying one unified record.

5.4.13. The platform’s ILS must support SQL-based database reporting, non-SQL based database reporting, and supports metadata schemas with the option of simultaneous use of Dublin Core, EAD, AACR2 and RDA.

5.4.14. The platform’s ILS must provide seamless integration with following OCLC® subscription services: WorldCat, WorldCat Connexion® and ILLiad® /WorldShare Interlibrary Loan.

5.4.15. The platform’s ILS must support authority record creation and automatic authority record updates from either Library of Congress (LC/LOC) or Online Computer Library Center (OCLC).

5.4.16. The platform’s ILS must allow authorized staff to configure various aspects of the ILS without Vendor intervention.

5.4.17. The platform’s ILS must support Unique record IDs for patron records.

5.4.18. The platform’s ILS must have the capability to easily link or tag patron accounts with a Master patron account.

5.4.19. The platform’s ILS must allow for automated holds with ability for staff to manually override the hold, both staff and patron ability to customize criteria to fill a hold, and the ability to put hold on an on-order record.

5.4.20. The platform’s ILS must have an Inventory Function.

5.4.21. The platform’s ILS must support record edit trail, including:

5.4.21.A. Date created 5.4.21.B. Created by (username) 5.4.21.C. Date last edited 5.4.21.D. Edited by (username)

5.4.22. The platform’s ILS must provide the ability to prevent patrons from placing holds or recalls on defined item types such as course reserve statuses.

5.4.23. The platform’s ILS must provide cataloging function/API (Application Programming Interface) in order to create localized MARC records.

5.4.24. The platform’s ILS must maintain relationships between items, including unique item specific metadata, and items in owing library.

5.4.25. The platform’s ILS must have workflow management capabilities that track the movement of collections materials for their entire process of acquisition, accession, cataloging, utilization, and deaccession. This requires the system to track property through its lifecycle.

5.4.26. The platform’s ILS must have a statistical dashboard to report the latest tabulated statistics on the number of items in each collection and the usage of items by type and location.

5.4.27. The platform’s ILS must have the ability to support global editing with proper user level permissions for bib/item/patron records at both the local and consortium level.

5.4.28. The platform’s ILS must have customizable batch requests and actions including uploads, tasks, editing, exports, import of multiple formats in the system

5.4.29. The platform’s ILS must provide ability to automate a bulk user load process (i.e., new incoming students each class) to bulk import patron records from an external source using LDAP within Blackboard.

5.4.30. The platform’s ILS must have the ability to allow for renewals in patron record (while viewing items out), during both check-out and check-in processes. ILS must allow for renewal of a single item that is checked out as well as multiple selected items checked out to a patron.

5.4.31. The platform’s ILS must have the ability to allow multiple staff users to view the same master bibliographic record but only allow one user to update at any time.

5.4.32. The platform’s ILS must have an offline circulation module that is compatible with Microsoft Office, preferably Excel for situations where server is not available and offline data must be able to be uploaded when the server becomes available.

5.4.33. The platform’s ILS must be able to activate or deactivate patron check out history.

5.4.34. The platform’s ILS must be able to create temporary bibliographic and item records “on-the-fly”.

5.4.35. The platform’s ILS must automatically generate a notice to patrons when requested items are available.

5.4.36. The platform’s ILS must be able to have a process to recall items with automatic notices sent to patrons.

5.4.37. The platform’s ILS must support the coexistence of local and consortium lending rules including the capability to customize lending rules such as the ability to determine/provide loan periods and renewal policies when dealing with consortium lending without interfering with local loan, renewal, and hold policies.

5.4.38. The platform must support management and display of license terms and conditions in machine-readable format to include linkage to digital resources; communicating key usage terms to users and staff at the local and consortium levels.

5.4.39. The platform must provide ability to upload and edit publisher(s) license documents and view history of edits/versions on the local and consortium levels.

5.4.40. The platform’s ILS must provide ability to assign different loan periods at the copy level to individual titles that have multiple copies.

5.4.41. The platform’s ILS must provide the ability to assign course reserves to one or more…