This week we decided to push Foundry towards a fully featured FOLIO distribution, with a practical first purpose: helping us build better connections between library and museum collections systems.
Rob Tice and I have talked for a long time about the intersection of galleries, libraries, archives and museums: GLAM. Our proposed mod-ciim module for FOLIO would bridge library workflows and collections management through CIIM, Knowledge Integration’s Collections Information Integration Middleware.
To develop that properly, we need broad coverage of FOLIO’s modules in an environment we can afford to run, change and rebuild. Foundry can meet that need. Making full FOLIO deployments more accessible is becoming a central purpose of the project.
FOLIO for museums, archives and research libraries
A museum’s library, an archive’s finding aids and an institution’s object collections can describe closely related material while living in different systems. Staff and researchers need useful connections between them. That creates questions about identifiers, metadata, updates and the relationship between a library record and the wider collection.
This is familiar territory for K-Int. CIIM integrates information from collections systems and other sources, with examples including the Science Museum Group and iMuseum for Manx National Heritage. The proposed mod-ciim work would bring that experience into closer conversation with FOLIO.
For us, the obstacle has been finding a suitable target environment for speculative development. A shared FOLIO Snapshot is useful, and production deployments have their own priorities. Between them, we need somewhere to try an integration, keep a particular combination of versions, investigate failures and repeat the experiment.
FOLIO’s runtime complexity makes that a substantial commitment before an idea has proved its value. Mod-ciim needs a broad system around it, so a small isolated demonstration will only take us so far. Reducing the effort and cost of running that system could help other developers and cultural heritage organisations explore their own ideas too.
From our development environment to a broader distribution
Foundry began with our own module development in mind. When we changed Agreements or Licenses, Foundry would be the environment in which we tried the work before releasing those modules for wider use.
That led us towards independently published applications, runtime composition and a clearer route from source changes to deployable software. It also informed our work on sustainable FOLIO development and, more recently, Foundry Release Control.
The two address different parts of the same practical problem: sustaining the engineering behind software, and making its releases understandable and usable.
We have asked “why not the whole of FOLIO?” before. Mod-ciim now gives that direction an immediate use case. This week’s decision is to work through the remaining integration and operational work towards a full distribution. Initially we will use it ourselves to support mod-ciim development. Over time, that could become a FOLIO distribution shaped specifically around galleries, archives, museums and their libraries.
This week’s first core module: Source Record Storage
We added FOLIO Source Record Storage (mod-source-record-storage, or SRS) as the first core backend in this expansion beyond the existing K-Int application suite.
SRS was a useful starting point because its dependency set is relatively small, while its Kafka interactions exercise something important for future CIIM integration: changes travelling between services as events. For mod-ciim, understanding when information changes will matter alongside being able to retrieve it.
This week’s work covered Kafka’s installation configuration, availability checks and delivery of connection details to modules. We checked actual event publication and consumption locally, alongside SRS tenant provisioning and repeat runs. SRS is now provisioned in our UAT-A workspace, where its API responds successfully.
It also helped us refine a repeatable onboarding process. Release Control correlates the upstream publisher’s build with its available container image, selects it under a channel policy and produces an immutable distribution revision. The Release Registry signs and publishes that definition; Foundry imports it for workspace selection and deployment.
Adding SRS alongside existing applications exposed a provisioning-ordering defect. We corrected that and added checks to reject cyclic plans before execution. We also introduced an optional module-specific database account with a separate tenant-role grant step. That is a reusable provisioning facility for modules that need it, including SRS; existing applications retain their established bindings.
Both fresh and already populated database installations were exercised locally. The resulting UAT-A provisioning completed with the previous applications, settings and file allocations preserved. These are useful lessons to carry into the next module onboarding.
Channels: choosing how an environment moves forward
Release Control is becoming the place where independently published components meet an explicit version-selection policy. A channel should let an organisation express which stream of software it wants to follow, while retaining an inspectable record of what was selected.
SNAPSHOT is the working proving ground today. Choices such as LATEST, or a named FOLIO release family such as SUNFLOWER, describe the further channel options we want to make straightforward. Those additional choices remain rollout work.
Our Snapshot workspace already has a scheduled nightly rebuild using the selected release stream. Other environments can keep their chosen versions and adopt updates deliberately. A newly available module still needs to be enabled once in Console; subsequent scheduled rollouts retain that selection. Publishing SRS therefore makes it available without silently adding it to every workspace.
The operational details matter too
Alongside SRS, we brought the ILL Directory application into Snapshot this week. We improved ordinary workspace upgrades and corrected Console’s reporting of ready versions after new applications are enabled.
The module inventory now offers a “Hide removed” toggle, defaults to module/version ordering and marks the latest known artifact versions. Those details help answer an everyday operational question: what is running here, and why? As the module set grows, a list of container names alone becomes harder to interpret.
The broader FOLIO integration is still in progress. Further module dependencies, workflows, compatibility and production readiness need their own qualification. This week’s milestone gives us a working SRS integration and a stronger process for the next one. Mod-ciim itself remains development ahead of us.
Interested in FOLIO and collections management?
If you are exploring FOLIO for a museum library, archive, gallery or specialist research collection, we would like to understand the connections you need between library services and collections management.
That might start with a development environment, a metadata integration or a conversation about a future deployment. Our goal is to make those first steps affordable enough to try, and to let real GLAM requirements shape the distribution as it develops.
Talk to Knowledge Integration about FOLIO, Foundry and CIIM, or explore our collections integration work and the Foundry development notebook.