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 Technical/Dependency-driven Perspective

...

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.

Gap Analysis and Incremental Progress

...