Following the Technical Council’s acceptance of the Application Formalization RFC, there have been many meetings, WOLFcon presentations, and ad-hoc discussions about a closely related topic: Application composition. This refers to the specific groupings of modules into applications. The purpose of this document is to describe an approach to answering this question, with the aim of getting those who are interested aligned.
The plan consists of two parallel efforts attacking the problem from different angles:
The functional/product perspective
The technical/dependency-driven perspective
The goal here is to define the ideal composition of applications, this gives us something concrete to work towards.
Technical dependencies can be ignored here, e.g. while MARC and Inventory are very tightly coupled right now, it doesn’t need to be that way forever.
This effort is led by those on the “product” side of the project. PC members, SIGS, SMEs, etc.
There are several things which should be considered here:
Application granularity, i.e. the size of applications. Not all applications will be the same size. Some may only be comprised of one or two modules, while others might include many more. If there’s functionality which is often considered optional/niche, we may want to create a separate application for it so it can be enabled when needed, but not for all libraries. Examples: GOBI, remote storage, LTI-courses, etc.
Known library configurations, i.e. what are some of the known, existing configurations? How can applications be composed to support them? For instance, some libraries only want acquisitions and ERM functionality, but not inventory or circulation. Would the applications as defined allow for that, or would a bunch of “extra” functionality be pulled in? This goes hand-in-hand with application granularity.
New functionality, when possible, should be added in the form of applications, instead of just modules.
The goal here is to split apart the so-called “mega” applications into smaller, more manageable pieces. Some of this work will require code changes, others can be split out right now will little effort. It’s important to note that this is not a one-and-done situation. We will need to iterate on this as things evolve/mature, making incremental progress over time.
This effort is led by architects and executed by developers.
Coming Soon: Additional details on the approach we’re taking here.
Application dependencies exist, and always will. It’s ok for applications to depend on other applications. That said, one of the goals here is to avoid the situation where you literally need to enable ALL applications or none of them because there are so many interdependencies.
Circular dependencies are problematic. At the moment, modules which depend on each other must reside in the same application. These may be good candidates for adjustments/refactoring as to unblock further refinement of the applications these modules comprise.
Tight coupling exists in many areas in Folio, where it shouldn’t or doesn’t need to be. This is one or the major hurdles we face in this effort. Addressing this will require some work. Documentation describing various techniques, when they’re applicable, their pros and cons, etc. is forthcoming. Example: orders has required dependencies on several inventory interfaces. Ideally these would be optional dependencies, allowing orders to be used w/o also requiring inventory.
New modules should not be added to the mega applications. Doing so is only making this effort more difficult. Instead new applications should be created. If needed, these can always be combined with other applications, split up further into additional applications, etc. later on.
Once we have made progress on both fronts, we can analyze the gaps between the current application composition and where we want to eventually be.
This is an iterative approach, where we make incremental progress toward the ultimate goal coming out of the functional/product perspective. Each iteration includes:
Analysis of how to further refine applications in the next iteration
Decoupling of modules in the current applications. This will facilitate the splitting of large applications into smaller applications.