2024-03-27 Formalization Working Group Meeting notes

• Craig's announcement from slack:
  • As mentioned at the meeting earlier, the Architectural PoC Preview environment is now available.  Please see the google sheet linked below for details.  This document will serve as a mechanism for providing feedback/questions/etc.  Please let me know if you have problems accessing the document.https://docs.google.com/spreadsheets/d/1zzW2I1xMhdUpkclQRE2NvCcvx6JlNYUG4aTOiaYraJ4/edit#gid=1733306425
• Application formalization RFC has moved to public review stage:
  • https://github.com/folio-org/rfcs/pull/29
• Wolfcon
  • Check in with EBSCO about sessions. Could we do something joint
  • A reporting out session? A working session?
    • A workshop style session would be better than just reporting out
    • Broader community wants to talk about this stuff, what is the framing?
    • Where do we think we will be at that point? Add a place holder?
    • Still figuring out on EBSCO end what to submit, do want to give updates, especially LC context and moving ahead with some of the concepts there. Also follow up on last WC

Copied to new doc because things were chaotic https://docs.google.com/document/d/1SdsRmeTLXQRpaC-6xy4sUfoOsNPN2dh2lPSnjwVZNk0/edit

Next steps

• Understanding initial grouping would be helpful
• Understanding day one impacts is impacted by the initial grouping
  • Who makes initial call of the applications, impacts how the dependencies manifest on day one
• Triage
  • What questions really need to know the grouping
  • What have we answered
  • What need input from outside the group
  • What is provisionally answered but dependent on other decisions
  • If after that figuring out initial bundling then ok
• Day one concept
  • Breaking down into smaller processes, not needing everything done for day one
  • Pick a domain and start working
    • Work through process of identifying the applications in a domain
    • Some domains involve grouping and some breaking up
  • At some point EBSCO's work will be added and there will be an intention to distribute applications?
    • What needs to be done when that happens
    • The first flower release based on applications rather than module release
    • The stuff outside of the technical work
  • Goal to eventually refactor into some applications
    • for ex, acquisitions application
    • breaking out pieces from the application
  • Is there value in defining one application?
  • Get enablers in and then iterate on the applications themselves
• Charge to answer questions from the councils
  • Unsatsifying!
• Applications
  • start here with dependencies
  • start with application descriptor   most inter dependencies, fewer  external dependencies
• The other stuff
  • how we actually use applications
• LC work will come in in the form of applications
• How to fix existing code vs new applications
• New LC apps, even people in legacy could introduce new applications. New applications come in as applications
• Stuff - go from oh good new application descriptors the community actually using the descriptors to build their systems
  • Folks need to actually be using them to get the value
  • things in community, getting new tech in, getting all of that in and getting all of the stuff
    • processes
    • communication
    • changing different ways of how things will be managed going forward

zoom chat:

00:03:57	Jenn Colt:	https://folio-org.atlassian.net/wiki/spaces/CC/pages/116031510/2024-03-27+Formalization+Working+Group+Meeting+notes
00:12:13	Kirstin Kemner-Heek:	+1 to the placeholder
00:23:31	Wayne Schneider:	Dependencies are currently based on interfaces
00:24:27	Marc Johnson:	Reacted to "Dependencies are cur…" with 👍
00:25:24	Craig McNally:	Replying to "Dependencies are cur..."

and that doesn't go away.  Modules still need to declare their interface dependencies
00:25:57	Craig McNally:	Replying to "Dependencies are cur..."

it's just that the dependencies are summarized at the application level as well
00:26:02	Marc Johnson:	I didn’t think we had decided what the application boundaries are
00:27:04	Wayne Schneider:	Replying to "Dependencies are cur..."

As interfaces or as module versions (i.e. implementations of interfaces)?
00:27:29	Charlotte Whitt:	Yes please split out MARC Authorities, SRS our of Inventory :-)
00:27:49	Tod Olson:	Replying to "Dependencies are cur..."

I think we will need to move towards interfaces.
00:28:05	Tod Olson:	Replying to "Dependencies are cur..."

But that will also be a big change.
00:28:28	Craig McNally:	Replying to "Dependencies are cur..."

an example may help...  just a moment
00:28:32	Marc Johnson:	Replying to "Dependencies are cur…"
It will still be interface versions at the module level AFAIK

At the application level, its application to application AFAIK
00:28:40	Charlotte Whitt:	Replying to "Yes please split out..."

Yes, quickMARC should also be it’s own app. Similar to MARVA (BibFrame) is going to be
00:29:15	Wayne Schneider:	Replying to "Dependencies are cur..."

And the application is composed of versions of interfaces or versions of modules? I think the examples give versions of modules.
00:29:43	Wayne Schneider:	Replying to "Yes please split out..."

Didn't authorities move to mod-entities-links in Poppy? (a minor point)
00:29:58	Marc Johnson:	Where do MARC source records live in this new world?
00:30:15	Marc Johnson:	Replying to "Dependencies are cur…"
The application versions is composed of module versions
00:30:46	Charlotte Whitt:	Replying to "Where do MARC source..."

It should be it’s own storage, similar to Data Graph Storage (or what it is called today)
00:31:08	Craig McNally:	Replying to "Dependencies are cur..."

mod-foo provides interface foo and depends on interface foo-storage
mod-bar provides interface bar and depends on interface bar-storage
ui-foo depends on interfaces foo and bar.
app-foobar is comprised of mod-foo, mod-bar, and ui-foo. 

mod-dit provides the dit interface and depends on interface foo
ui-dit depends on interface dit.
app-dit is comprised of mod-dit, ui-dit. and has a dependency on app-foobar.
00:31:08	Kirstin Kemner-Heek:	But if I break up a lot of modules being their own app -> do I still have the advantage to save effort by "bundling"?
00:31:51	Craig McNally:	Replying to "Dependencies are cur..."

I've left versions out of the example above for simplicity, but they are present at the interface, module and application level
00:32:04	Marc Johnson:	Replying to "Dependencies are cur…"
Does app-foobar include the storage modules that you defined the example as well?
00:32:06	Kirstin Kemner-Heek:	Replying to "Dependencies are cur..."

+1 Craig. That explains :-)
00:32:45	Wayne Schneider:	Replying to "Dependencies are cur..."

Thanks. So applications are composed of particular implementations of interfaces (i.e. versions of modules).
00:33:03	Charlotte Whitt:	Replying to "Yes please split out..."

I could be wrong. But  MARC authorities use Elastic Search, and that was the reason for the decision to build it into Inventory
00:33:05	Marc Johnson:	Is there a contract at the application level?
00:33:52	Marc Johnson:	Replying to "Yes please split out…"
It’s probably built into mod-search

Which is both general and inventory specific, so where does that belong because ui-inventory needs it?
00:34:41	Charlotte Whitt:	Proper sizing is that a ‘same size all bundled modules’ or size fitting the given bundled modules
00:35:14	Craig McNally:	Replying to "Dependencies are cur..."

@Marc Johnson that's ambiguous in my example (sorry).  

mod-foo-storage provides interface foo-storage
mod-bar-storage provides interface bar-storage
mod-foo provides interface foo and depends on interface foo-storage
mod-bar provides interface bar and depends on interface bar-storage
ui-foo depends on interfaces foo and bar.
app-foobar is comprised of mod-foo, mod-foo-storage, mod-bar, mod-bar-storage, ui-foo. 

mod-dit provides the dit interface and depends on interface foo
ui-dit depends on interface dit.
app-dit is comprised of mod-dit, ui-dit. and has a dependency on app-foobar.
00:37:05	vbar:	Snakes and ladders is a maybe not the best metaphor since it entirely based on chance (dice) with no skill involved. 🙂
00:37:52	Marc Johnson:	Replying to "Snakes and ladders i…"
By all means substitute for a more appropriate game 

Apologies if I incidentally offended
00:41:33	Marc Johnson:	In the past, teams have made decisions that are impacted by Conway’s Law and we’ve ended up with smaller parts because of team responsibilities
00:45:44	Craig McNally:	Replying to "Proper sizing is tha..."

Proper sizing IMO doesn't mean that all applications must have the same size.  Rather, it means applications don't have "too much" or "too little" in them
00:57:05	Marc Johnson:	Have I completely misunderstood how we are intending to roll out applications?
01:03:39	Craig McNally:	I have to run.. thanks guys
01:04:39	Charlotte Whitt:	FOLIO legacy … 😅