For the past few decades, the traditional law library has been transformed by the digitization of statutes, regulations, and commentary. Law Librarians and KM professionals have become the curators of an ever-expanding universe of commercial, dynamic data sources including company profiles, competitor profiles, experience data, insights into judges, experts, and arbitrators, deal data, dockets, and news. These data elements, when aligned and merged with internal administrative systems, can deliver strategic insights to power the ongoing evolution of the business and practice of law.
In my last column, I referred a panel at this year’s AALL conference, The Law Library’s Role in Data Integration, APIs and Attorney Workflow Initiatives, which provided a goldmine of practical tips, experience and wisdom. During that panel, Erik Adams, the Manager of Library Digital Initiatives at Sidley Austin, provided an excellent “Checklist for Evaluating an API”, which is reprinted below with his permission.
Checklist for Evaluating an API
Starting points (These can be answered by non-technical staff.)
□ Does the API satisfy an information need?
□ Is there another API or resource with the same information?
□ What will the API cost?
□ Will the API support a service provided directly to your institution’s users (i.e. law firm clients), or will it support an internal group?
□ Can the costs of the API (if any) be recovered?
□ Will the API have a large number of users, or will it be a niche product?
□ Are any of your peer institutions using the API?
Non-technical things to look for (A vendor representative can probably answer these questions if the answers are not easily found on the Internet.)
□ Is there documentation for the API?
□ Is there formal support available directly from the vendor?
□ Is there a community of users that can provide informal support (i.e. a Reddit forum or a vendor hosted discussion web site)?
□ Are there user groups or conferences for the API?
Somewhat technical things to look for (A vendor representative or friendly developer will be needed for these questions.)
□ Is there sample code that demonstrates how to use the API?
□ Is the sample code in the programming language preferred by your institution (i.e. for C# and .Net for law firms, Python for academic institutions)
□ Will the data need to be processed or combined with data from another source to be useful?
Really technical things to look for (A developer will be essential for these questions.)
□ Can the new API be easily integrated into existing systems?
□ Is the API easy to understand?
□ Is the documentation good?
It can be daunting to know where begin with data APIs. In spite of being such a trend, there is little practical guidance around on how to actually implement them. Fortunately, the AALL panel provided some basic advice for getting started on an API project.
- Identify use cases with internal and external stakeholders.
- Evaluate both the data and the potential vendor.
- Gather requirements and define the problem you want to solve or the process you want to improve.
- Collect current data sources including taxonomies and vocabularies.
- Consult subject matter experts regarding content and technology.
The panel also discussed a variety of use cases for APIs. A client dashboard can integrate internal and external client data including a company profile, news, recent litigation, internal client billing information, documents in progress. APIs can track and analyze competitive intelligence and business development projects. News and docket feeds can be customized and integrated with internal data and distributed for business development. Client portals can provide custom reports, documents, and curated data from internal and external sources. APIs can also be used to automate the updating of databases or spreadsheet data.
One Piece of Advice from Each Panelist…
I asked each panelist to provide me with one piece of advice for readers who want to start an API project.
Dave DiCicci (Senior Director of Product Management at LexisNexis):
“Your API planning should be a highly collaborative process. Meeting with your vendor to whiteboard and document your workflow and the proposed solution helps you find an accurate solution to your organization’s unique challenges. With LexisNexis, it’s a highly consultative process. We like to have conversations with firms to understand exactly what their desired use cases are before we suggest the right API solution. In March of 2022, we launched the interactive LexisNexis Developer Portal to educate developers and allow them to make test calls against live data so they simplify the coding process."
“I would say my top piece of advice is that an API is not the be-all end-all goal. This applies both to businesses looking to use APIs, and to the businesses rushing to create them. We talked about this in the session: APIs are building blocks (like LEGO!), but by themselves they don’t really do anything. Like any technology, they are part of a puzzle and it takes investment by people with industry expertise and technical know-how to make APIs actually contribute to a business.”
Keli Lea Whitnell (Senior Experience Database Manager at Troutman Sanders):
“The vendor is just as important as the API/data (maybe even more important), so don’t discount the small and hungry vendors! Ask questions about the vendor in addition to the data: What is your development process/pipeline and product vision? Are you selling access to someone else’s data or proprietary data? How do you incorporate client feedback? How do you resolve reported data issues, including missing and incorrect data?”
Emily Rushing (Director of Competitive Intelligence at Haynes & Boone LLP):
“Integrations of internal and external data can drive efficiencies and innovation in law firms, and librarians should be central to the discussions around that content and its use. Quoting the the chef in Ratatouille ‘Anyone can cook!.’ You don’t have to be a data scientist to create value for your firm and its use of APIs.”
Pam Noyd (Information Resources Manager at Foley & Lardner LLP):
“If you’re just starting to work with APIs, be assured that you know more than you think you do because we’re already using APIs in our daily lives. Librarians know the resources and have established vendor relationships so don’t get bogged down by or be afraid of the technical aspects. In the simplest of terms, it’s about the data and bringing it into a platform for your users to digest. Engage internal and external stakeholders early and often.”
It occurred to me that maybe the pandemic fostered the API revolution. Many library and KM teams were at the forefront of pandemic related projects. Tracking the ephemera from every level of government, aggregating, and parsing the data. Creating client-facing dashboards addressing COVID regulations for labor, insurance, privacy, civil rights, hospitality. In addition, the shutdown of a physical library certainly freed library directors and their teams from the management of physical collections. In addition, a remote workforce mandated the development of digital library solutions. Librarians and knowledge managers need to be key players exploiting the goldmine of commercial data sources for firm-wide API initiatives.