...
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 Policy, CLAMP, 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. The requirements Sub-Committee can evaluate and identify cross-interactions between proposals. The requirements S/C can make prioritization recommendations to the TSC. The TSC (with EUAG input) can then make a decision to adopt or alter the prioritization recommendations.
- #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 U/C Architecture Review Process Project Architectural Review Requirements and Process (Draft) U/C Architecture Review Template R7 Guilin Architecture Review (template) - functional 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 .
- #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.
- #8: ARCHITECTURE REVIEW - The use cases & requirements undergo Architecture Review
REVIEW STEP DESCRIPTION MODELING INPUT The Use case teams should engage the modeling sub-committee and schedule their use case into the model planning page before architecture review. They should identify information is consumed, produced, and utilized by their use case. This should also be scheduled in the Model Planning page: ONAP R7 Modeling High Level Requirements
CROSS DEPENDENCIES Use Case teams should identify cross-dependencies upon other requirement/use cases and/or ONAP components cross-dependencies impacts. For example BBS dependent on PNF registration, it is nice to know about that dependency so that the two teams know to work together. This should be identified before the architecture review if possible.
CONTROL LOOPS Identify potential Policies and Control Loops that might be altered or new with your requirements/use case. API IMPACTS Use Case teams should identify API impacts. The team should highlight the differences between what exists today (the old API) and the new API that they expect to update it to. This should be put in the presentation made to the architecture review.
INTERFACE IMPACTS Interface (northbound and southbound) impacts should be identified
REQ JIRAS The release tracking Jiras should be created. See the ONAP Use Case / Requirements Teams Process Way of Working (WoW)
ARCH JIRA The Architecture Tracking Jira is created. The Architecture Chair will create the ONAPARC Jira tickets before the review. The reviews are scheduled week by week. Navigate to the Architecture Meeting Notes (weekly) ONAP Archecture Meeting Notes (Copy)
ARCH REVIEW When the template and checklist has been completed, create a presentation to walk through at the Architecture sub-committee and schedule a review. REQ to ONAPARC JIRA LINKING - LINK - Before a requirement may be reviewed by the arch subcommittee, the requirement must be documented in JIRA (REQ), and the REQ reference must be submitted when requesting an arch review.
- STEPS - After the arch review subcommittee has completed its review and made a determination, please add an issue link to the REQ issue for your review.
- Navigate to your requirement issue in JIRA (REQ)
- Select edit
- Scroll down until you find the "Linked Issues" field (see attachment)
- Make sure that the link type is "Is blocked by" (see attachment)
- Add the JIRA reference for your arch review (ONAPARC) to the "issue" field. (see attachment)
- Click the "Update" button.
- PLATFORM / PTL- High level release scope from PTLs (understand from PTL which ONAP components are expected to have updates). If a component is resolving technical debt or software development that is entirely self-contained.
- 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.
...
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) 5 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.
- #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.
Use this checklist to prepare for your Platform Component review:
Checklist Item Description Check Update Attachments Info
The "Attachment" folder associated with each Component (... in upper right corner) has also been cleaned up and all draft copies of the diagrams have been deleted.
All the associated files for the page are stored in the attachment folder. Click on the "..." in the upper right of the page
The on the page change the component name. Hit the "EDIT" and change the component name to the "Component name - R#", where R# is the release number.
Cross check the name with the tag.
Use Draw.io draw.io is the tool currently used to draw all the diagrams
When you edit the diagram it will open the Draw.io interface which looks like this:
Check Attachments Folder and Drawio Diagrams Each component diagram file has the following properties:
- componentName_r7 (i.e. sdnc_r7 for the SDN Controller)
- The .png file associated with your component gets generated by draw.io
- There may be other files/images left in the Attachment folder. feel free to modify/delete any file(s) to reflect the changes associated with the release. Remove unneeded png files (you can click on the png file and see if it is still relevant for the release, if it is not delete it otherwise we will be carrying this diagram as unnecessary overhead). If the "DELETE" option does not show up contact, the Architecture PTL/Chair to get assistance as they may own the older files.
- The draw.io diagrams (i.e. lollipop diagram) is based on the C4 Model for visualizing Software Architecture?? - Please maintain the same format as you make any changes to your respective component
- Each diagram has a release stamp (bottom right corner) that should not be modified
- Each API (consumed or offered) is depicted by a lollipop and a label. You may add, modify or delete any API as needed but please maintain the same look and feel and the diagram file naming convention.
COLOR CODE CONVENTION:
COLOR MEANING Status colour Red title RED Status colour Blue title BLUE
API Documentation The page should document the consumed or offered API, and to provide as much detail and clarity on the what and the how of each API. With that in mind i'd like to propose the following as a starting point for preparing for these reviews:
PTLs /Representatives will be responsible for making all the changes to their respective component diagrams
PTLs would certify and approve all the changes to their respective component diagram
Each API listed on the component diagram (lollipop and Label) should:
be fully documented in the corresponding table, included in component wiki page above,
- each API label should have a link to their respective swagger.xxx, REST, YANG, wiki page, etc...
- #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).
- ARCHITECTURE SUBCOMMITTEE leading up to M1 -
APIs producing consuming at architecture review
...