Page Comparison

...

• M1

  • ARCHITECTURE SUBCOMMITTEE leading up to M1 -
    
    • #1 FUNCTIONAL ARCHITECTURE (Requirements) - The functional reference architecture is the high-level architecture overview diagram for all of ONAP. Enhancements to the functional architecture may be driven by new project proposals, updates to the diagram, and architectural changes that may be planned for the release. At M0 impacts to the functional architecture are proposed.
    • #2 COMPONENT ARCHITECTURE (Requirements) - The component architecture impacts originate from the ONAP platform components. Examples of platform components are SO, A&AI, CCSDK, SDN-C. Each release there may be architecture impacts from the platform components. At M0, component architecture impact proposals are submitted.
    • #3 REQUIREMENTS ARCHITECTURE (Requirements) - These are architecture impacts coming from the requirements and use case work in a release that may impact the functional architecture, platform architecture, or may need architectural guidance. At M0, the requirements and use cases are being proposed for the release. And an early assessment of which ones that might impact the architecture should be considered, and they made translate into requirements architecture proposals.
    • #4 ARCHITECTURE ENHANCEMENTS (Requirements) - Architecture enhancements are secondary architectural enhancements that are worked during a release. These may include documentation enhancements, landing page enhancements, architecture component description work, flow descriptions and process work. At M0, initial proposals are submitted to the architecture sub-committee.
  • WIKI LINKS References for Architecture at M1

    • The following table has the links for important M1 architecture pages

      WIKI LINKS REFERENCE AT M1
      M1	DESCRIPTION	WIKI LINK
      1	Architecture Portal Page	https://safratech.net/onapdocs/
      2	Architecture Release Page
      3	Milestone Checklist	Deliverables for Planning Milestone Checklist Template
      4	Architecture Review Checklist	Project Architectural Review Requirements and Process (Draft)
      	Architecture Dashboard	Architecture Dashboard

      
      

  • USE CASE TEAMS - The Use Case Teams prepare their proposals. The Use case teams are defining their requirements and detailed proposals.
    
    • #1 RELEASE PLANNING TEMPLATE - Use Case teams use the release planning template to help you think about your scope, minimum viable product, architecture, risks, and epics. The release planning template can be found here: Release Planning Template
    • #2 MILESTONE CHECKLIST - The milestone checklist template are used by the Use Case teams. This checklist can be found at this wiki link: Deliverables for Planning Milestone Checklist Template
    • #3 PROJECT DELIVERABLES - are defined including functional architecture, scope, dependencies.
    • #4 MODELING TEAM WORK - The model subcommittee team becomes aware of the use cases for the current release.
    • #5 EARLY DATA MODEL CONCEPTS - Because the information model feeds the data models, the Use Case teams should take into account the new updates in the information model as a basis for their data model.
  • Project & Release planning tables
    

    • The architecture checklist is from the Deliverables for Planning Milestone Checklist Template  and Project Architectural Review Requirements and Process (Draft)

      AREA	CHECKLIST ITEM	LINK
      Architecture	Project PTLs/Feature Sponsors request a review by email from the chair of the arch subcommittee.
      	The chair of the arch subcommittee creates a JIRA issue for the review and emails a link to the project PTL.
      	The project PTL/Feature Sponsor adds the JIRA issue link to the architecture review JIRA task in the M1 epic, as confirmation that a review has been requested.

      
      

  • Modeling team The info-model plan is established by the modeling team which summarizes the modeling requirements for a release. The model planning follows a template that is worked by the team. Info-model updates begin. An example template for R6 (Frankfurt) can be seen at this Wiki: ONAP R6 Modeling High Level Requirements.
    • #1: SYNC - The Use Case teams need to engage the Modeling Sub-committee to make the team aware of model impacting use cases. The modeling team should also become aware of at a high-level what impacts a use case might have. The use cases also need to get into the ONAP Modeling High-level requirements planning page.
  • Components (PTL)- Each of the ONAP platform components (e.g. A&AI, SO, Controllers, SDC etc) may be impacted by new use cases. Having the use case leads engage PTLs.
    
    • #1: COMMITMENT & TRACKING - The data model developed by the use case teams eventually serve as the basis for API changes. Platform components need to update APIs based on new requirements, use cases and features. Requests to components need to be tracked & commitment by the PTLs and components. Ideally the PTLs and component leads should be engaged by the Use Case teams. SDC & A&AI often have more high-running modeling impacts than some of the other components. The modeling team members could attend some of the component calls to raise awareness. Identifying and tracking a modeling impacting item so they aren't lost. An issue impact matrix and tracking page could be developed to track issues (and maybe a Jira ticket).
      
    • #2 RELEASE TRACKING PAGE - The release tracking page also tracks the platform components.

...