ONAP ARCHITECTURE TEAM PROCESS OVERVIEW
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.
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, 2019:
Link here: https://lf-onap.atlassian.net/wiki/download/attachments/16428505/master-onap-diagram-frankfurt-jun-10-2020-v3.png?version=1&modificationDate=1591809506030&api=v2
COMPONENT ARCHITECTURE - The component architecture are the platform components. Examples of platform components are SO, A&AI, CCSDK, SDN-C. Each release there may be architecture impacts from the platform components. Component development may come from resolving technical debt and from new requirements work.
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. These may include documentation enhancements, landing page enhancements, architecture component description work, flow descriptions and process work (this wiki page!)
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 |
|---|
| M0 | FA - Proposal Architecture Team | CA - Proposal from PTLs | FcA - Proposal Dev U/C teams | AE - Proposals Architecture Team |
|
|
| M1 | FA - Review | CA - Requirements | FcA - Requirements | AE - Requirements |
|
|
| M2 |
| CA - Review | FcA - Review | AE - Review |
|
|
| M3 | FA - Baseline | CA - Baseline | FcA - Baseline | AE - Baseline | Sync |
|
| M4 |
|
|
|
|
| Sync |
Diagram showing interaction with other sub-committees
Release Planning (legacy)
Frankfurt Release M3 API Freeze Milestone Checklist
Use Case Teams Process per M-gate
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
- 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
- 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.
- #3 COMPONENT REVIEWS - The component reviews are trying to baseline the understand of the component in the release. Each of the project or project teams should give a presentation at the architecture sub-committee. The focus of the component reviews is to ensure that the documentations provided in these wiki pages are consistent with what the state of each ONAP component for a specific release.
M2
- ARCHITECTURE SUBCOMMITTEE leading up to M2 -
- #1 FUNCTIONAL ARCHITECTURE (Architecture Reviews) - 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 (Architecture Reviews) - 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 (Architecture Reviews) - 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 (Architecture Reviews) - 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.
- Use Case Team Engagement -
- FUNCTIONAL TEST CASES - Each Project team has defined and documented their Functional Test Cases.
- API DOCUMENTATION - The Use Case Teams have identified the API that they will be introducing in the current release and at least started to document that API changes that are associated with their use case. The APIs need to be documented and available in the Use Case Wiki.
- VNF REQUIREMENTS - Base set of impacts to VNF Requirements identified by use case/ project.
- INFORMATION & DATA MODEL DEVELOPMENT - Discussion Info Model & Data model development by Use Case team with input from the Modeling sub-committee. Active discussion and interaction between Use Case Team and the Modeling S/C to make sure that the information model and the data model development are in lock-step. The modeling sub-committee will communicate the clean release information model as a refining input to the development of the data model for use by the Use Case Teams on specific projects.
- INFORMATION & DATA MODEL REVIEW - Reviews of Data Model with Project (Use Case) Teams. The Data Model is being reviewed by the Use Case Teams with inputs from the Modeling S/C by bringing the developing data model (in the discussion state) to the modeling S/C. It would not be feasible to for the members of the modeling S/C to attend all of the various U/C meetings; although one-off sync-ups might occur in this stage. For those U/C that have significant data modeling work, it would be advised that that U/C team reserves a slot in the modeling S/C meeting(s) to present their data modeling changes and information flows so that the modeling S/C team can advise the U/C team as they develop their data model.
- MAPPING BETWEEN INFORMATION & DATA MODEL - Mapping of information model and the data model is also done between the modeling S/C and the Use case teams. This might happen in the project teams, or on the modeling S/C calls.
- CROSS REFERENCING JIRA TICKETS - The modeling S/C uses Jira tickets to track activities; and the Use Case teams also use Jiras to track platform work, modeling work, epics & stories. So it would be smart to link or associate relevant Jira tickets together.
- JOINT REVIEWS - The Data model should be reviewed with the Modeling S/C. Data model being developed by the component team is using the component model as input.
- FUNCTIONALITY IDENTIFIED - The release intended functionality has been identified, agreed to and frozen. No new visible functionality is to be added to the current ONAP release at the point of M2.
- MODELING SUBCOMMITTEE -
- For the RELEASE Information Model these are the activities that the Modeling sub-committee is engaged in leading up to M2.
- RELEASE INFORMATION MODEL (Starting Point) - The release starts with a clean release information model from the PREVIOUS release (with all of its attendant contributions). Then new contributions of the current release are considered (see below the process for handling each specific contribution). Potentially a snapshot of the papyrus model and posted into the current release. The RST documentation that only contains things in the current release or everything that is approved.
- INFORMATION MODEL FREEZE - The aggregate / release information model for the release is approved by association with the fragment/ component reviews. Each of the fragment (contributions) are individually approved, thus there is not a "re-approval" or approval of the entire aggregate (release) information model. Editorial clean-up such as misalignments, typos, or sections that were not put in proposal, fixing the template for GenDoc.
- RELEASE INFO MODEL DECLARED CLEAN - After component reviews have concluded and release info model freeze by the modeling S/C the info model is called the "clean model" in this phase. At this point, the Use Case teams that are developing the Data Model can be pretty certain that the information model will be usable as shown. The diagrams and model wiki pages will indicate that this is a clean model. Put into the information model for that release. Unfinished contributions are postponed or discussed further.
- DISCUSSION OF CONTRIBUTIONS - Each contribution discussed according to following process. This is where refining of each of the contribution models occurs by the Modeling Sub-committee (S/C). The release information model is not separately tracked, composed, updated, or released in this period of time. But, rather, each individual contribution has its own Wiki. Thus, for each contribution:
- CONSIDER CONTRIBUTION - START: Input Contribution (verb Consider) END: Contribution in Discussion State
- An individual model contribution is a model that will eventually be a part of the total release information model. It is generally a self-contained model which depicts a particular capability or function of the system. This contribution starts as a "input contribution" and undergoes consideration by the modeling sub-committee. Consideration means that the modeling S/C is entertains & assesses if the input contribution should be accepted into the current (or a future release) by weighing the contribution against its relevance and the available resources (modelers) in the release. If the team thinks that the contribution is not ready for the current release that contribution will be put into a lower-priority and worked if there are no other contributions to be considered as they would take higher priority. Thus, the contribution would not necessarily be rejected, but would get attention as time allows.
- REVIEW & REFINE CONTRIBUTION - START: Contribution in Discussion State (verb Reviewing & Refine) END: Contribution in Discussion state
- The contribution undergoes reviewing & refining during the discussion state. Reviewing & refining means that the modeling S/C is discussing the modeling, and updating the contribution based on feedback and comments from the modeling team. Each contribution can be reviewed and refined independently and concurrently with other contributions. Things in the discussion state are classes, attributes and relationships are tagged as IISOMI experimental.
- FINAL CALL FOR COMMENTS & INITIATE POLLING - START: Contribution in Discussion State (verb Approving/Poll) END: Contribution in Discussion state. The modeling team issues a call for comments and poll for each contribution.
- APPROVING CONTRIBUTION - START: Contribution in Discussion State Post-Poll (verb Approving) Contribution in Clean State
- After the poll has concluded, the contribution has finished the approval process. The contribution is now considered to be in the clean state. The items that are in the IISOMI experimental state get promoted to a preliminary state. A gendoc is generated and put on the wiki page. The gendoc would be translated and published on the readthedocs site.
- Components (PTL) Engagement - ONAP Platform Teams (A&AI, SO, SDC etc) review clean Information Model impacts for the release.
The M-drop Summary
| Drop | Functional Architecture | Component Architecture | Requirements Architecture | Architecture Enhancements | Info Model | Test Cases |
|---|
| M0 | FA - Proposal Architecture Team | CA - Proposal from PTLs | FcA - Proposal Dev U/C teams | AE - Proposals Architecture Team |
|
|
| M1 | FA - Review | CA - Requirements | FcA - Requirements | AE - Requirements |
|
|
| M2 |
| CA - Review | FcA - Review | AE - Review |
|
|
| M3 | FA - Baseline | CA - Baseline | FcA - Baseline | AE - Baseline | Sync |
|
| M4 |
|
|
|
|
| Sync |
M3 API Freeze
- ARCHITECTURE SUBCOMMITTEE M3 -
- #1 FUNCTIONAL ARCHITECTURE (Architecture Base-lined) - The functional reference architecture is the high-level architecture overview diagram for all of ONAP. This should be base-lined by M3. 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 (Architecture Base-lined) - The component architecture impacts originate from the ONAP platform components. Examples of platform components are SO, A&AI, CCSDK, SDN-C. This should be base-lined by M3. All of the details of your APIs, JSON objects should be defined and base-lined and ready. Each release there may be architecture impacts from the platform components. Once the API/code freeze at M3 the PTLs should know if there have been recent changes that need to be reflected in the Architecture documentation. The Architecture chair could sync and confirm if that they reviewed in the Architecture S/C for M2 is still valid at M3.
- #3 REQUIREMENTS ARCHITECTURE FROM USE CASES (Architecture Base-lined) - 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 M3, these requirements coming from use cases should be base-lined. My M3, the architecture should be documented, and finalized. If the Arch S/C has all the resources available, another quick review should be held to assess if anything new has changed since the review. A quick sync or update should be given to the Architecture Sub-committee.
- #4 ARCHITECTURE ENHANCEMENTS (Architecture Base-lined) - Architecture enhancements are secondary architectural enhancements that are worked during a release. These may include documentation enhancements, the architecture portal landing page enhancements, architecture component description work, flow descriptions and process work. At M3, these may continue to be worked by the architecture sub-committee and continue to be discussed.
- Use Case Engagement -
- API Freeze - The Use Case Teams at this point have base-lined their APIs and their Data Models. Component data model schemas. Who maintains them should be identified, and these should be presented at the Architecture sub-committee.
- M3 MODELING SUBCOMMITTEE ACTIVITIES -
- REFINEMENTS TO THE RELEASE INFO MODEL - The Release Information Model is clean at M3. It is considered "base-lined" and "final", hence it is marked clean. Though, updates can still happen to the release information model and the model contributions therein.
- INFO MODEL OBJECTIVES - What do they mean to intend and convey by the information model and the changes for the release what are the key objectives. And how does the information model relate to the data model.
- SYNC - Work underway still by the modeling sub-committee, such as refinements to the release information model, items still in progress, future work, and work documented after implement should be communicated to the architecture sub-committee in a sync-up before M3. The modeling sub-committee lead should reach out to the Architecture PTL either for a quick sync, a separate 1-off presentations, or reserved slots on either of the two regular weekly team calls.
- Components (PTL) Engagement -
- PTL READOUT - The PTL should reaffirm for their component, their architecture proposals that were made at M2, to make sure there have not been significant deviations from their original proposal. And if there have been updates to report back to the Architecture Sub-committee on the deltas.
M4 Code Freeze
- ARCHITECTURE SUBCOMMITTEE M4 -
- #A TEST CASES (Architecture) - At M4, unit testing is done where APIs and interfaces are tested. A checkpoint what was discussed at M2 and M3. The APIs could be tests based on the designs that were tested. For example, the NBAPI may implement some actions. These actions might be CRUD operations. The team could report that some part of it was tested and some needs to be pushed to the next release.
- #B PTL UPDATES (Architecture) - PTLs are managing S/W deliveries at Code Freeze, and testing is occurring. Feedback from the integration team. Unit testing needs to happen within the component. The pair-wise testing exposes tests the interfaces between components, reviewed at the component reviews.
- #C COMPONENT DIAGRAM UPDATES (Architecture) - If swagger JSON files needed to be made, the links to the swagger files should be updated from their component reviews.
- #D NEXT RELEASE ARCHITECTURE FOCUS - Discussions are happening around what the focus of the Architecture efforts for the next release are happening. For example at the end of R7 the Architecture sub-committee was discussing aligning the Platform component wiki pages, and also the next steps for the Architecture flow diagrams that were started in R4.
- #E DOCUMENTING THE ARCHITECTURE - Documenting the architecture is an ongoing effort. Each release will open discussions about how to best document the Architecture. It helps to have a focus on a particular topic per release to make the work more manageable. Read the Docs should be updated and reviewed. Architecture Read the Docs, and APIs should be up to date by end of M4. And the ONAP Architecture overview in the read the docs should be updated.
- #4 ARCHITECTURE ENHANCEMENTS (Architecture Base-lined) - Architecture enhancements are secondary architectural enhancements that are worked during a release. These may include architecture portal landing page enhancements, architecture component description work, and process work. Because the teams are fully engaged trying to meeting delivery deadlines, the Architecture enhancements are fully self-contained activities within the Architecture sub-committee they can continue to evolve during M3, M4 and RCx. For example, suggestions for common templates can be discussed in this time frame. This also sets the stage for making the focus of the next release more coherent.
- Use Case Engagement -
- API - Use case teams that are impacting the APIs and thus the component swagger should also report on changes to the component pages.
- Components (PTL) Engagement -
- API & Component Descriptions - Updates to swagger/JSON files should be reflected in the component pages.
RCx (Runtime Compliance)
- ARCHITECTURE SUBCOMMITTEE at RC0/RC1/RC2 -
- #A RELEASE CERTIFICATION - The API reviewed were the ones that were tested by the integration teams. The high-level requirements drive the low-level requirements. They would drive test cases. Test cases are run, if they pass and there is something that is wrong with the requirements/epics/user stories, the test cases don't change and then re-test happens. The feedback with a problem they need to make sure that problems are also notified in the architecture sub-committee.
- #B NEXT RELEASE ARCHITECTURE FOCUS - Discussions are happening around what the focus of the Architecture efforts for the next release are happening. For example at the end of R7 the Architecture sub-committee was discussing aligning the Platform component wiki pages, and also the next steps for the Architecture flow diagrams that were started in R4.
- #4 ARCHITECTURE ENHANCEMENTS (Architecture Base-lined) - Architecture enhancements are secondary architectural enhancements that are worked during a release. These may include architecture portal landing page enhancements, architecture component description work, and process work. Because the teams are fully engaged trying to meeting delivery deadlines, the Architecture enhancements are fully self-contained activities within the Architecture sub-committee they can continue to evolve during M3, M4 and RCx. For example, suggestions for common templates can be discussed in this time frame. This also sets the stage for making the focus of the next release more coherent.
- Use Case Engagement -
- Sync - Any major changes arising from the Use Case teams can be socialized to the architecture sub-committee at this point. They can then be addressed in the next release if necessary or action can be taken in the current release.
- Components (PTL) Engagement -
- Sync - Any major changes arising from the Use Case teams can be socialized to the architecture sub-committee at this point. They can then be addressed in the next release if necessary or action can be taken in the current release.
ARCHITECTURE ARTIFACTS
ROLES – ARCHITECTURE SUB-COMMITTEE
SUPPORTING LINKS & DOCUMENTS
