The following diagram illustrates the overall Architecture Process. It shows the basic stages of a release, going from M0 (release kickoff), to M2/M3 (API Freeze) and to code delivery in M4.Components. ONAP defined a new release process, based on the agile ONAP Streamlining evolution. It simplified ONAP release process, by having only:
- Kick Off
- Release Candidate
- Sign Off
The previous M0 (release kickoff), M2, M3 (API freeze) and M4 (code freeze) processes are merged and will be handled between Kick Off and Release Candidate in an agile manner, as the following:
- Marketing release Kick Off, RC and Sign Off dates are set by Release manager and TSC
- Each PTL determines their project agile cycle(s) based on their features
- PTLs/Feature owners work with ARCCOM/SECCOM/TSC/Release Manager/OOM/INT and DOC
- Each agile iteration/sprint is reviewed / approved by the project team (and ARCCOM/SECCOM/INT/TSC/Release Manager/TSC as needed)
- priorities, guidance, standards, security...
- The review outcome is used to determine what the next steps until RC
There are It illustrates 5 stages that the Architecture teams are concerned with, the Functional Architecture requirements, to component architecture reviews and architecture improvements.
...
FUNCTIONAL ARCHITECTURE - The functional architecture is the high-level architecture overview diagram for all of ONAP. This was the Functional Architecture diagram on May 16, 2019April 2024:
COMPONENT ARCHITECTURE - The component architecture are the platform defines ONAP network automation components. Examples of platform components are SO, A&AI, CCSDK, SDN-C, CCSDK, SDN-C, CCSDK, UUI, Portal NG, DCAE, Multi-VIM/Cloud, Policy Framework, SDC and CPS. Each release there may be architecture impacts from the platform components
REQUIREMENTS ARCHITECTURE - 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.
ARCHITECTURE ENHANCEMENTS - Architecture enhancements are secondary architectural enhancements that are worked during a release. It would be part of ONAP Streamlining release cycles. These may include documentation enhancements, landing page enhancements, architecture component description work, flow descriptions and process work (this wiki page!)
Note: the following milestones will be processed all together in an agile manner/iteration; i.e., no separated individual milestones.
Some key things the happen at the milestones:
M0 - Functional Architecture Proposals, Component Architecture Proposals, Requirements Architecture Proposals
M1 - Functional Architecture Review, Component Architecture Requirements, Requirements Architecture Requirements, Architecture Enhancements Proposals
M2 - Component Architecture Reviews & Base-line, Requirements Architecture Review & base-line, Architecture Enhancements Reviews
M3 - Functional Architecture base-lined, Information Model sync, Architecture Enhancements review & base-lined
M4 - Test Case review and Architecture consistency.
Drop | Functional Architecture | Component Architecture | Requirements Architecture | Architecture Enhancements | Info Model | Test Cases |
---|---|---|---|---|---|---|
|
|
|
| |||
| ||||||
Frankfurt Release M3 API Freeze Milestone Checklist
Use Case Teams Process
Note: the following use case milestones are for information only. ONAP does not use M0/M1/M2/M3/M4 milestones any longer.
MO
- ARCHITECTURE SUB-COMMITTEE - The following are M0 activities with the Architecture Sub-committee. Release content defined.
- #1 FUNCTIONAL ARCHITECTURE (Proposals) - 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 (Proposals) - 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. Architecture reviews are setup & scheduled for component architecture impacts/proposals. Component architecture diagrams would be updated.
- #3 REQUIREMENTS ARCHITECTURE (Proposals) - 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. Architecture reviews are setup & scheduled for requirements architecture impacts/proposals.
- #4 ARCHITECTURE ENHANCEMENTS (Proposals) - 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 the Use Case Teams at M0
WIKI LINKS REFERENCE AT M0 M0 Description Wiki Link 1 Functional Reference Architecture Architecture 2 Architecture Portal Page https://safratech.net/onapdocs/ 3 Release Architecture Page All of the architecture reviews that were conducted:
4 Requirements Proposals Mod Modeling Release Planning Page ONAP R7 Modeling High Level Requirements - Modeling team - At MO the Modeling S/C does MODEL PLANNING. The planning develops into “High Level Info-model Requirements”. These High level info-model requirements fall into 3 categories:
- #1: NEW USE CASES - items from the expected Use Cases in the release (Scope of modeling, continuing, introducing, standards updates). The Use Case Teams should engage the modeling team to propose new requirements into their release planning page.
- #2: REFINING EXISTING MODEL - Refining Existing info-model that has not made it to the information model. Previously designs that need to be added into information model.
- #3: FORWARD LOOKING WORK (FLW) - Modeling future forward looking requirements.
- USE CASE TEAMS At M0, the Use Case teams are working on the following things:
- #1: BUSINESS DRIVER TEMPLATE - The Use Case Teams are specifying their business drivers via the template: Business Driver Template for Use Cases
- #2: REQUIREMENTS SUB-COMMITTEE - Develop their proposals for the release to the Requirements Sub-committee: Requirements subcommittee (is merged into ARCCOM)
- #3: REQUIREMENTS RELEASE TRACKING - Requirements put release requirements page. Example wiki: Guilin release - functional requirements proposed list
- #4: USE CASE DEFINITIONS - Use Case team fill out the Template detailing their Use Case: Use Case Tracking Template
- #5: INTENTION TO PARTICIPATE - Teams can indicate their corporate intention to participate
- #6: RELEASE TRACKING - Each release has a release tracking page. The page can be found here: Release Planning
- #7: PROJECT SUBMISSION, PROPOSAL, PLANNING - The TSC coordinates the project submission, proposal and planning. The TSC reviews and gives disposition on submitted proposals. These are tracked at the Release Planning page.
- PTL- High level release scope from PTLs (understand from PTL which ONAP components are expected to have updates)
- PTL - The Use Case teams should attend the PTL planning meetings if there are expected to be requirements impacts for your use case. It is also where the Release Planning page is developed by the PTL team.
- ARCHITECTURE SUB-COMMITTEE - The following are M0 activities with the Architecture Sub-committee. Release content defined.
...