...

1. Logistics

   1. Flights? 
   2. Hotels (hold off)
2. Defining the outputs of the fly-in
   1. Review of VIVO components and interfaces
   2. Features to carry forward and leave behind
   3. Diagrams
      1. Duke (Richard)
      2. Rialto (Justin)
      3. Opera (Brian)
      4. Cornell (Huda) - see below
3. Homework for Dec 20th meeting:
   1. Rough, brainstorm architecture diagram of decoupled VIVO
4. Meeting schedule leading up to Jan 29th
   1. Dec 20th @noon ET
   2. Jan 10th @noon ET
   3. Jan 24th @noon ET

Notes 

Audio recording

• 2018-12-06-vivo-fly-in-planning.mp3

From last week's actions:

• Diagrams
  • Cornell (Huda)
    • VIVO (in general)
      • From the wiki: diagram from architecture overview page
        • component diagram from main architecture page
      • Can include more brainstorming/high level component diagrams/discussions from presentations and documents as well but not sure this is the bullet for it
    • Scholars at Cornell
      
      • Presentation: https://figshare.com/articles/Scholars_Cornell_Visualizing_the_Scholarship_Data/5277958/1 (Slide 19 shows a high level overview of the components)
      • Data Distribution API structure:  
        • image which  shows API-related components (these would connect to VIVO)

Discussion

Outputs

1. step through features
   • mark as in/out/optional
   • logical grouping into modules

Artifacts

1. We must review / augment / categorize / annotate the feature list
   1. Answering the questions:
      1. What will the product will do/support?
      2. What additional business value-add can the re-architecture offer?
      3. What are core? and why?
      4. Which features are in/out/optional?
      5. What audiences are specific features for?
      6. What are the logical groupings for features into modules?
2. Anticipated products that will come out of the fly-in
   1. Architectural diagrams
      1. Top-level and Detailed, component-level
      2. APIs and services, specified
3. Also noted, we should have an Architectural Framework independent of the feature list
   1. How will we support modularity?
      1. i.e. Will each module be able to be compiled separately?
      2. What is the framework for swapping in replacement modules?
4. We should consider defining goals, but the focus is on design and architecture
   • Short and Long term
5. Questions: 
   1. To what degree do we keep the legacy code vs. replacement?
      1. It is the data that bridges the past and present
   2. Are we talking about VIVO only, or VIVO/Vitro
      1. What are the community implications of collapsing VIVO/Vitro?
6. Principles:
   1. Components must be configurable and extensible
      1. Although we will not be able to develop every feature, the architecture should allow others to
      2. For example, the web layer must support adding widgets
7. To what degree do we need to bring security (filtering) reqs forward
   1. Is this in line with VIVO principles?

...