Date

Ingolf shared this background info: Technical needs met when standing up FOLIO installs
Okapi service self-discovery desired
The release process (3 per year, maybe going down to 2)
Releases offer less new functionality, more emphasis on stability
Dependencies among modules are really complex
Upgrades of modules become problematic b/c of the dependencies
One wouldn't expect this in a microservices platform architecture, should be more agile, that was the original idea of FOLIO
"App store" concept? Some librarians don't want that. Not clear that we're really able to say FOLIO is truly following a microservice philosophy or an app store model. Having true CI/CD processes is also challenging in this architecture.

Next steps

Need to better boundaries set defining what are core modules and what are "external"
Focus on the general pain points, don't get into the details yet at this stage. The goal is to make it easier to adopt FOLIO. We see a lot of issues reported on Slack by people trying to install the system.
Anton shared a diagram illustrating the complexity and challenges in releasing new versions: Kiwi (R3 2021)
- All the necessary testing is very difficult to accomplish (UI/UX testing, integration testing, BugFest manual UAT)
- Juniper testing went pretty well, and there weren't as many major bugs as in previous releases. Many of them were able to be fixed. However, some libraries who tried to install Juniper had issues.
There's a potential opportunity to collaborate with the Technical Council on these questions. Tod and Phil are on the TC as well as this SIG and can help with that collaboration. Down the road, the next WOLFCon could be an opportunity for it.
Having better module boundaries could resolve a lot of the major issues around the release cycle.
- Ex Circ: inventory, fees/fines, users, permissions, check in / check out .... all in different modules. Why not built into okapi as the central gateway? Each module's domain is defined too wide, need to freeze the whole system to upgrade
- Just checking out fires off a bunch of HTTP calls to a bunch of modules, which increases checkout time
- Interactions with patron blocks, circ rules, fees/fines etc
Action item: let's pursue implementing better module boundaries, in conjunction with the TC and developer teams.

Documentation of Integrations

Let us return to the List of Integrations which we had discussed earlier.

Discovery Integration will be a good starting point.

Here is the Spreadsheet we discussed: FOLIO Source Data and Integrations (in particular, see the "Detailed Inventory" tab)

Also, look at this whole section: List of Integrations - System Operations and Management SIG - FOLIO Wiki

There's still concern about the lack of ownership of the SSO module, and it doesn't have all the features (authorization etc) that libraries want. Seems to be low priority to fix among the community though.
- Axel shared this discussion for reference: https://discuss.folio.org/t/saml-sso-features-and-strategy/2891
- We need more critical mass of support from libraries to move SSO forward, and get it prioritized.
- The SysOps SIG could be the champion as the SIG of Integrations.
We should focus on the integrations libraries need that require more work
Discussion of the remote storage module with Caiasoft and Dematic
Z39.50 support is important to many libraries too
Should the SIG distribute a survey to the libraries on integrations? The Implementers' SIG could be a suitable target audience for good coverage.

Meeting Notes

Good conversation with Product Council (PC)

Action items

James - Create Wiki
Ingolf - Talk to people to get us invited to PC/TC

Browser not supported