Global Best Practices for Library Automation

When a library decides to automate its operations or upgrade its existing system, it faces a fundamental question: how do you choose a system that actually works for your users and staff, while staying flexible enough to survive the next wave of technology? Libraries around the world have wrestled with this for decades, and over time a set of shared standards, planning tools, and design principles has emerged. These global best practices help libraries avoid expensive mistakes and build systems that can talk to each other. This post walks through three pillars of that knowledge: the recommendations from the Open Library Environment and the ILS Discovery Interface, the role of the Request for Proposals in defining what a library needs, and the major trends now reshaping automation worldwide.

OLE and ILS-DI recommendations 🔗

Two influential initiatives shaped how the library community thinks about modern automation. Both emerged around 2008, and both reacted to the same problem: traditional integrated library systems (ILS) were rigid, built around print workflows, and difficult to connect with other software. Understanding what each proposed helps explain why today’s systems are designed the way they are.

The Open Library Environment (OLE) 🔗

The Open Library Environment Project was funded by the Mellon Foundation and led by academic libraries in the United States, Canada, and Australia. Its goal was not to release a single product but to produce a design document for a next-generation library system. The core idea was to think beyond the traditional ILS and design something flexible, customisable, and capable of meeting the complex needs of modern academic libraries.

A few principles defined the OLE vision and remain useful best practices for any library evaluating automation:

Service Oriented Architecture (SOA): OLE recommended building systems on a modular SOA approach rather than as one monolithic package. This means individual functions-circulation, acquisitions, cataloguing-work as connected but independent services. Libraries can modify or replace parts without rebuilding the whole system.

Breaking from print-based workflows: The project deliberately moved away from systems designed mainly around printed books, recognising that libraries increasingly manage licensed and digital content alongside physical items.

Integration with enterprise systems: OLE stressed that a library system should mesh well with the broader software an institution uses, such as finance and student records, rather than sitting in isolation.

The OLE design work eventually fed into FOLIO, an open, extensible library services platform developed through a collaboration between the OLE community, EBSCO, and Index Data. An earlier build attempt called Kuali OLE was eventually discontinued, and the libraries involved moved their efforts toward FOLIO. The lesson here is practical: the design principles outlived any single piece of software, which is exactly why they are studied as best practices rather than as a finished tool.

The ILS Discovery Interface (ILS-DI) 🔗

While OLE focused on the overall design of library systems, the ILS-DI Task Group, convened by the Digital Library Federation (DLF), tackled a narrower but critical problem: how should an ILS share its data and services with separate discovery applications? At the time, many libraries wanted to use modern search interfaces in front of their catalogues, but connecting them to the underlying ILS required custom, proprietary work for each system.

The ILS-DI recommendation proposed a standard set of application programming interfaces (APIs) so that any discovery tool could work with any ILS. After a key 2008 meeting, the group produced what became known as the Berkeley Accord, an agreement on the most essential and feasible interfaces to include first. These core functions were called the Basic Discovery Interfaces.

The recommendation grouped roughly twenty-five abstract functions into four broad categories-data aggregation (harvesting records in bulk), search, patron services (such as holds and renewals), and OPAC integration (linking to outside services). It then organised these into four levels of interoperability:

Level 1 – Basic Discovery Interfaces: the minimal functionality needed for a discovery interface to work with an ILS.

Level 2 – Elementary OPAC supplement: adds the ability to supplement the existing catalogue with harvested records.

Level 3 – Elementary OPAC alternative: enough functionality for a discovery tool to act as an alternative to the built-in catalogue.

Level 4 – Robust or domain-specific discovery: the fullest level, supporting real-time availability, linking, and advanced features.

This tiered approach is itself a best practice. It lets libraries and vendors adopt interoperability gradually, starting with the basics and building up, rather than facing an all-or-nothing decision. A DLF survey at the time found that more than 40% of responding institutions were considering a new ILS within two years, and over three-quarters were already using external discovery tools alongside their catalogue-evidence of how urgently this standardisation was needed.

The role of requests for proposals 🔗

Recommendations and standards tell a library what good automation looks like. The Request for Proposals (RFP) is the practical document that turns those ideals into specific requirements a vendor must meet. For most libraries, the RFP is the single most important tool in selecting a new system.

What an RFP actually does 🔗

An RFP is a structured document a library issues to vendors, inviting them to submit competitive proposals for supplying and implementing a system. The American Library Association describes the RFP as the heart of a library system purchase, representing a coordinated effort by staff to produce a coherent statement of the library’s mission, needs, and expectations. Its purpose goes beyond procurement: along with the winning vendor’s response, it becomes the foundation for the working relationship and the agreed schedule between the library and the supplier.

A well-built RFP forces a library to do something valuable before spending any money-to define clearly what it needs. The acquisition of a library system demands substantial time, expertise, and patience from staff, and the RFP is where that thinking gets documented. It typically comprises instructions to bidders, functional and technical requirements, hardware and support specifications, acceptance testing criteria, and reliability requirements.

How libraries define their needs through an RFP 🔗

A practical insight from experienced librarians is that no vendor will satisfy every requirement. After receiving proposals, staff select the product that strikes the optimal balance between price and desired function. To make that comparison fair, many RFPs ask vendors to respond to every requirement using a standard scale-for example, marking each feature as fully available, optional, or not planned.

Modern RFPs increasingly reflect the same trends shaping the wider market. A recent RFP from a community college district asked for a system capable of supporting the entire lifecycle of a resource-acquisition, description, management, and circulation-for both physical and electronic materials, while safeguarding patron privacy and security. Others now require vendors to specify whether their offering is cloud-hosted software-as-a-service or installed on local servers, and to address accessibility for differently-abled users. These additions show how RFPs evolve to capture changing expectations.

For libraries operating with public funds, the RFP also serves accountability and fairness goals. It promotes open competition among vendors and creates a documented, defensible basis for the final decision-an important consideration for any institution spending money from a public budget.

Global trends influencing library automation 🔗

The standards and tools above set the foundation, but the ground keeps shifting. Three technological trends are now driving how library systems are designed and chosen. Market analysts repeatedly point to the convergence of cloud computing, AI, and data analytics as the force positioning the automation market for rapid growth.

Cloud computing and library services platforms 🔗

The clearest shift is the move from locally installed software to cloud-based platforms. Instead of running an ILS on servers inside the library building, institutions increasingly subscribe to a hosted library services platform managed by the vendor. Industry forecasts highlight the growing adoption of cloud-based platforms for scalable and flexible management, alongside demand for mobile-friendly access and unified handling of both digital and physical resources.

The advantages are practical. Cloud systems reduce the burden of maintaining hardware and applying updates, scale up or down as needs change, and make remote access easier for staff and patrons. This is especially relevant for smaller or rural libraries that lack dedicated IT staff. It is also why so many RFPs now ask vendors to clarify their hosting model upfront.

Linked open data and the move beyond MARC 🔗

For decades, library cataloguing has rested on the MARC (Machine-Readable Cataloging) standard, developed at the Library of Congress in the 1960s. MARC has been remarkably effective for sharing records among libraries, but it was never designed for the modern web, which leaves library data somewhat isolated from the wider information universe.

The response is BIBFRAME (Bibliographic Framework), a linked-data model intended to replace MARC. Rather than treating a catalogue record as a single, self-contained block of text, BIBFRAME breaks bibliographic information into connected entities-works, instances, items, agents, and subjects-expressed as linked-data statements. This lets library metadata connect with external knowledge sources such as Wikidata and ORCID, improving discovery and making library data usable far beyond the catalogue.

The transition is gradual rather than sudden. Most libraries still rely on MARC, and a true switch is complicated because so many connected systems depend on it. Practical approaches let MARC and BIBFRAME coexist, so libraries can introduce linked data slowly while keeping familiar workflows. The Library of Congress has even introduced conversion tools and a bridging strategy to keep modern linked data usable by libraries still on traditional systems. For students, the key point is that the question is increasingly about when a library moves to linked data, not whether it will.

AI-driven cataloging 🔗

The newest trend is the use of artificial intelligence to assist with cataloguing and metadata creation. The volume of digital material libraries must describe has grown faster than staff can keep up with using manual methods alone, and AI offers a way to scale.

The Library of Congress has experimented in this area, testing machine-learning models on roughly 23,000 ebooks to predict metadata such as titles, authors, subjects, and dates. Crucially, the design philosophy favours a human-in-the-loop approach: the machine suggests possible subject headings or author names, and a professional cataloguer reviews and selects from them. The principle that emerges is important-AI is positioned to augment rather than replace human catalogers, combining processing power with professional judgement.

Commercial vendors are integrating these capabilities too, with tools that can generate descriptive metadata for special collections or even identify faces in photographs. Large bibliographic networks are also applying AI at scale; one major cooperative reported adding more than 400 million linked-data entities to its records and using AI models to de-duplicate records across formats and languages. The direction is clear: AI, linked data, and cloud delivery are converging into a single modern approach to library automation.

Bringing the best practices together 🔗

These three pillars connect more closely than they first appear. The design principles from OLE and the interoperability levels from ILS-DI explain why modern systems should be modular and able to share data. The RFP is the tool a library uses to demand those qualities in writing. And the trends in cloud computing, linked data, and AI are what a well-written RFP must now anticipate, so that the system chosen today does not become obsolete in a few years. A library that understands all three is far better placed to make a confident, future-ready decision.

What do you think? If your library were issuing an RFP today, how heavily would you weigh a vendor’s support for linked data and AI features against the system’s current cost and ease of use? And do you believe the human-in-the-loop model for AI cataloguing is sustainable as the volume of digital material keeps growing?

References

1. https://www.niso.org/niso-io/2008/08/open-library-environment-ole-project-planning-open-ils-systems
2. https://www.folio-bib.org/wp-content/uploads/2018/05/2018-04-25-winkler-FOLIO-Community.pdf
3. https://old.diglib.org/architectures/ilsdi/DLF_ILS_Discovery_1.0.pdf
4. https://cdlib.org/cdlinfo/2008/08/25/digital-library-federation-dlf-releases-technical-recommendation-from-ils-discovery-interface-task-group/
5. http://infomotions.com/blog/2008/06/dlf-ils-discovery-internet-task-group-ils-di-technical-recommendation/
6. https://libguides.ala.org/librarytech/rfp-writing
7. https://go.gale.com/ps/i.do?id=GALE%7CA106473733&sid=googleScholar&v=2.1&it=r&linkaccess=abs&issn=00242586&p=AONE&sw=w
8. https://pima.edu/administration/contracts-purchasing/docs/p23-10054l-rfp-integrated-library-system.pdf
9. https://www.verifiedmarketreports.com/product/library-automation-systems-and-services-market/
10. https://www.researchandmarkets.com/reports/6090398/library-services-platform-market-global
11. https://en.wikipedia.org/wiki/BIBFRAME
12. https://exlibrisgroup.com/blog/from-marc-to-bibframe-what-linked-data-means-for-libraries-in-practice/
13. https://liblime.com/2025/11/13/digital-transformation-how-libraries-are-implementing-ai-in-2025/
14. https://www.oclc.org/en/annual-report/2025/home.html