Feedback/Ideas on Consortial “Infrastructure” Needs

The Consortia SIG is discussing “Infrastructure” as a consortial service as identified in our Consortial Services Framework document. Since hosting member libraries’ ILS is a fundamental service for many consortia, this is an important component to get right in building FOLIO for consortial capabilities.

What needs does your consortium have when it comes to sharing an ILS?

Specifically, here are some areas we’ve started discussing:

• How do you foresee libraries in your consortium being represented in a FOLIO instance (i.e. single shared tenant, one library per tenant, etc.)
• What data do you need to share across libraries? Conversely, what needs to be restricted?
• At what granularity does data sharing/restriction need to happen (i.e. entire consortium, individually selected libraries within consortium, individual staff or staff roles, etc.)?

I see the issue of single-shared-tenant vs. one-library-per-tenant as being a fundamental architectural decision for the FOLIO project, and not one that would be made on a discretionary basis by an implementing consortium. The reason for this is that the structural implications on your second and third questions are huge depending on which way you go. Designing FOLIO to be able to handle both scenarios and also maintain sufficient flexibility with respect to data sharing and restriction is a nearly impossible task, and would create significant complexity for non-consortial libraries.

I am an advocate for the one-library-per-tenant model, because I see it as fundamentally cleaner and simpler to create data sharing across tenants, rather than create the partitions needed to support restrictions within tenants.

I see the partitions/no partitions question as part of the decision making process when a consortium such as FLO is considering FOLIO options. Along the lines of:

• Need partitions that are more extensive than those needed by a single institution with multiple libraries (since single institutions with multiple libraries may need the ability to restrict data access and/or data modification by library, staff role, etc) Choose one-library-per-tenant
• Don’t need much complexity? Choose shared tenancy.

That makes sense. I guess it becomes important to know where that complexity boundary lies with respect to the FOLIO implementation and architecture.

I think the problem could be looked at as a marking question for FOLIO. If public library systems would be the most likely to want multiple libraries on a single tenant system, then theirs would be the target consortial features to provide on a single FOLIO instance. I wonder if a survey for consortia could be done to get a perspective on this?

So I think I’d agree with Tania. From my perspective in a consortium with three libraries in three different institutions currently sharing a single Sierra system we deal with many frustrations which I think we’d prefer to solve by going to a multi tenant system. If the promise of lower cost hosting and support for FOLIO becomes a reality then this is the way I’d see our consortium going.

To that end the functionality that we would need to exist across FOLIO instances would be seamless ILL management and knowledge base / marc load integration for consortial purchases to lessen maintenance requirements for each library. Seems like the consortial marc record loads might be getting into some muddy waters now that i think about it.

This gets into knowledge base features, but what if one tenant of FOLIO could create and publish it’s own knowledge base package? Say “all the books we are willing to ILL”. Then the other libraries in the consortium could just check off that package to allow patrons to search and request those books. The same system could be used for an “All e-resources this consortium provides to it’s members” package. My apologies if this is getting off track or already has some proposed solution I wasn’t aware of.

I would think that in a multi-tenant consortial setup, marc loads could be accomplished via some kind of propagation API with “special” users having access to it. For example, say you have a consortium that three tenants, but they share an e-book package subscription for which periodic updates are necessary. You’d have an user in one tenant that has api permissions like “consortial marc loader” and they can mark a marc load as a consortial marc load and it would be propagated to the rest of the consortium on load.