VBar presented a distilled version of the proposal to formalise definitions of applications and platforms in Folio (as presented recently at WolfCon 2023), focussing on non-technical aspects. The talk can be viewed in the recording of the PC meeting at https://prod-zoom-recordings-openlibraryfoundation-org.s3.amazonaws.com/276819cf-e9a6-4071-b72f-3bfb01131bbc%2Fshared_screen_with_speaker_view(CC).mp4. The presentation starts at 00:09:00 (nine minutes into the recording). If prompted for a password use folio-lsp
There were a number of questions, many addressed in chat and some addressed at the end of the talk. The chat is transcribed and the spoken questions and answers are below.
Following the presentation and Q&A Kristin Martin asked "What are the things that the PC could be doing in service of seeing if we can make this a reality or what things we could contribute?" as a primer for potential further action from the PC, but this was not discussed further in the meeting.
Presentation Chat
Note the chat is threaded and represented here with any threaded comments shown after the message at the top of the thread, preceded by a > and in italics. Timestamps (in Eastern) have been left in so they can be more easily matched to the recording, but comments have been reordered into their respective threads and reactions grouped together to improve readability
10:16:11 Owen Stephens: “Domains” seems to introduce a new piece of terminology - what is meant by the 22 domains?
> 10:19:04 Craig McNally: I'll let Vince answer, but I believe that Domains were used as a tool during the analysis to help group modules - sort of a first pass before assigning modules to applications.
>> 10:19:13 Owen Stephens: Reacted with 👍
10:17:59 Peter Murray: On the previous screen "mod-gobi" was put into "Orders" -- how does something that is not Gobi work its way into Orders if there isn't a defined API? Is there a "Gobi-Orders" and a "<something_else>-Orders"?
> 10:20:39 Craig McNally: mod-gobi is in the "GOBI application". I think what you saw was that it was attributed to the "orders" domain. (see my response to Owen's question above).
> 10:20:58 Tod Olson: I believe that spreadsheet is a POC experiment on organizing rather than proscriptive. That is, there's some arbitrariness and I would expect whatever the project would settle on would be somewhat different from the POC.
> 10:22:51 Craig McNally: Right it was an experiment, and inherently imperfect (not to mention outdated -- it's a year and half old). The purpose was to determine if modules can successfully be grouped into a smaller number of applications. As Vince said the results of the experiment were positive... taking something 170 modules and combining them into 50 or so applications
> 10:23:55 Peter Murray: ...or 51 if mod-gobi is still separate? I'm questioning the premise that there can be a lot of consolidation when we don't know what was consolidated and the flexibility lost in that consolidation.
> 10:25:21 Craig McNally: I pulled up the spreadsheet... the exact numbers were 172 modules, 56 applications, 22 domains. Obviously, we need to revisit this, and determine what the exact mapping of modules -> applications look like. One consideration here is module interdependencies, which I don't think Vince looked at during his analysis. He may have, we'll have to ask.
> There's also nothing saying that we can't take an iterative approach here... so maybe we start by defining large applications with many modules (in order to satisfy dependencies, etc.)…. Then as we make adjustments to the modules to break down some of these hard dependencies we can start splitting up these large applications into smaller applications, closer to where we ideally want to be.
> 10:30:55 Peter Murray: Gobi has an interface for ordering. I don't know how portable it is, but presumably one could consider a Brodart or Oasis or Amazon ordering interface. How does this consolidation contemplate that need? (This is just one example that lept off the slide...not seeing the spreadsheet of proposed consolidation, there might be more.)
> s/interface/API/ -- it has a defined API that ideally is portable across more than one supplier.
> 10:34:09 Craig McNally: I think that would likely be handled by creating a application for each of those modules... so app-gobi [ mod-gobi ], app-amazon [mod-amazon], app-brodart [mod-brodart], app-oasis [mod-oasis]. If in a given deployment you only use gobi, you'd enable only the gobi application. If you use 2, or 3, or all of those, you'd enable the appropriate applications
> Some applications will have multiple modules, some will only have 1. Note that if there are corresponding UI modules for these, e.g. ui-gobi or ui-oasis, those would also be included into the applications
> 10:37:44 Peter Murray: So this is an expansion of apps, not a reduction. One of the core concepts to the FOLIO LSP to this point was that APIs are a definitional boundary between functional options.
10:35:46 Peter Murray: I'm not quite following...because we already have cases where one library's functional tier is not the next library's functional tier. The suite of ERM apps is a good example...that is all some libraries want. And within ERM there are differences between what apps our desired.
> 10:37:31 Craig McNally: To take the example from above... gobi/oasis/etc. These applications would be in the extended tier, and enabled on an as-needed basis. OTOH, the orders application would live in the functional layer of the ILS platform.
> 10:38:29 Peter Murray: All of the ERM apps would be in the extended tier?
> 10:39:00 Craig McNally: no, that's not what I'm suggesting
> 10:39:25 Craig McNally: let me check my understanding of what you're asking Peter...
> 10:39:33 Owen Stephens: I think this is part of the challenge just mentioned by Vince - there isn’t a right answer to any of these questions, but somewhere the community would need to decide what was the “FOLIO LSP” platform definition
>> 10:39:44 Craig McNally and Maura Byrne: Reacted with 👍
> 10:39:46 Owen Stephens: And how that divided between functional and extended
> 10:39:52 Craig McNally: Thank you Owen
> 10:40:41 Craig McNally: It's worth noting that if someone decides that the FOLIO-provided ILS platform isn't ideal for them, they can create their own which adds or subtracts applications as needed
10:40:06 Kristin Martin: So, would there be a Platform called, "FOLIO Core" on which other platforms "e.g., FOLIO ILS" or "FOLIO ERM" would run on top of?
> 10:40:43 Owen Stephens: I don’t think “Folio Core” is a platform in this definition - or at least not in the way that Vince has described
> 10:40:45 Tod Olson: Probably "FOLIO Core" looks more like a mandatory application.
>> 10:40:51 Owen Stephens, Jennifer Eustis and Maura Byrne: Reacted with 👍
> 10:41:24 Owen Stephens: There could be trivially a platform defined that has nothing in its functional and extended tiers
>> 10:41:46 Craig McNally and Maura Byrne: Reacted with 👍
> 10:41:47 Owen Stephens: But I’m not sure that would be helpful
> 10:42:16 Ian Walls: FOLIO core would need to be deployable as it's own thing in order for any kind of Application development to be possible
> 10:42:17 Craig McNally: Right, it's more like Folio Core is one (or more) applications which are required to have a working platform.
> 10:43:18 Craig McNally: It would be possible to have a platform w/o function or extended tiers. This would allow you to do nothing beyond login. Something along the lines of what we've been referring to as "platform minimal" in the community for a while now
> 10:44:12 Jennifer Eustis: how would the interaction look like between these applications? Here I'm think that right now we have limited cross app searching or cross app interaction that can be difficult like change instance connection or moving items with connected requests where the request doesn't also move?
> 10:44:47 Tod Olson: Needed interactions would still be via APIs, or possibly Kafka.
>> 10:45:17 Jennifer Eustis: Reacted with 👍🏻
> 10:45:09 Craig McNally: Right, this doesn't require modules to change. This is a layer on top of modules
10:45:42 Ian Walls: it would allow for lower-than-REST integration for modules within the same Application
10:48:28 Owen Stephens: Does the ‘core’ incorporate working parts such as okapi, Kafka, elasticsearch?
Presentation Q&A
The full spoken Q&A can be obtained from the recording. The questions and answers are paraphrased here, and any errors in paraphrasing are due to the note taker - please contactOwen Stephens if corrections are required.
Craig McNally noted there was some confusions/questions around:
- The application analysis carried out by Vince
- How to know which apps would belong to the functional vs extended tiers in a platform
- The exact nature of the "Folio Core" tier
- This is similar to the "platform minimal" concept
- VBar elaborated: The core allows you to have a running system where you can login but there is no other functionality - a working system that does nothing
Q (Hkaplanian): Do the application and platform descriptors already exist in Folio
A (VBar ): No they are both new. This is what I'm calling the "Formalisation")
Q (Owen Stephens): Does the ‘core’ incorporate working parts such as okapi, Kafka, elasticsearch?
A (VBar ): Yes
A (Craig McNally): This presentation omitted some technical aspects that are covered in more detail in the WolfCon presentations, those would be a good starting point for more detail
Q (Kristin Martin ): If you were a library and wanted to run both the ILS platform and ERM platform, would they need to have the Core tier for both platforms (multiple platforms multiple Cores), or would there only be a single "Core" shared across the platforms
A (VBar ): The "Core" is bundled in the platform. If you are running two platforms it is implicit that they are installed in a 'different place' and so each has it's own Core tier
Q (Kristin Martin ): So that implies that if you needed a whole set of funcitonality you would want to bundle that into a single platform to avoid duplicatons. e.g. if you wanted to run both ILS functionality and ERM functionality would you need a "FOLIO Complete" platform that incorporated both, or would you "grab" both platforms
A (VBar ): It depends on what your intentions are and why you have the separate platforms. In the example of ILS [aka LSP] + ERM, the ERM functionality is a subset of the ILS functionality and so would be included in the ILS [aka LSP] platform to start with. However other examples such as the idea of having a "FOLIO for Museums" would have a different set of functionality and so a separate platform with a different set of modules to the ILS [aka LSP] platform. Once you've decided which the base platform is best for your needs, you can always add more applications via the "Extended" tier
Q (Kristin Martin ): So the platforms are conveniently out-of-the-box bundles that we anticipate people wanting, but then they would be able to add and subtract applications as needed?
A (VBar ): Yes
A (Craig McNally ): Worth noting that the platform definition doesn't remove existing levels of control we have in FOLIO. Just because an application is part of a platform doesn't mean it absolutely has to be activated for a particular tenant
A (Owen Stephens ): Really important to take Vince's point that applications are not unique to a single platform. The LSP vs ERM platform examples used are simply examples of what platforms might look like and not intended to suggest that the LSP platform would exclude ERM functionality. More that any institution wishing to only use ERM and not the rest of the LSP functionality would have the option of running the ERM platform and thus avoiding all the non-required LSP functionality
Q (Owen Stephens ): Some of the challenges mentioned in the presentation were around making it easier to deploy applications to existing FOLIO installation. There is an underlying challenge that we currently try to fit all available apps into the "Flower release", but it would already seem this is not necessary (for example the Open Access app is being run by libraries even though it is not in a Flower release. How does the approach described in the presentation make things better, and why adopt this approach rather than using the existing ability to include, or not, modules in a particular FOLIO installation?
A (VBar ): It is true that it is already possible to do this and it is already done by various hosting providers and self-hosting institutions. The formalisation of the approach being proposed will make this easier and less error prone. The application definition will remove guess work from exactly which modules need to be installed to get a working set of functionality meaning fewer errors, and allowing us to work at application level rather than module level. This proposal is about formalisation providing a management structure around the modules, applications and platforms
Related WolfCon23 slidedecks