Table of Contents |
---|
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.
...
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:
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.
...
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
Frankfurt Release M3 API Freeze Milestone Checklist
Use Case Teams Process per M-gate
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 ARCHITECTUREARCHITECTURE (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 ARCHITECTUREARCHITECTURE (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. #4 ARCHITECTURE ENHANCEMENTS - 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, 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.
- ARCHITECTURAL "THEME" - A focus topic for the release, an architectural "theme" can also be communicated and socialized to the architecture sub-committee. For example in R7, there was a focus to shore up the API documentations.
WIKI LINKS References for the Use 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 Requirements subcommittee (is merged into ARCCOM)
Guilin release - functional requirements proposed list
6Release Tracking page Release Planning Mod Modeling Release Planning Page ONAP R6 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 Arch Architecture Component Descriptions ONAP Architecture Component Description - Guilin-R7 Docs Read the Docs https://docs.onap.org/en/latest/ - Modeling team - 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 should develop are specifying their business driver template and consider their purpose and business impact for their use case. This would detail the executive summary, business impact, business markets, financial impacts and management and strategy. The template for the business driver case can be found here: Business Driver drivers via the template: Business Driver Template for Use Cases
- #2: REQUIREMENTS SUB-COMMITTEE - Develop their proposals for the release which focus on defining their business imperatives. When ready, the Team needs to present their business drivers and requirements to the requirements sub-committee. The presentation are given to the Requirements Sub-committee: Requirements subcommittee (is merged into ARCCOM) .
- #3: REQUIREMENTS RELEASE TRACKING - After making a presentation to the Requirements sub-committee. Their requirements would then be put into the release proposed functional requirements page. An example for Release 7 (GuiLin) is at this Requirements put release requirements page. Example wiki: Guilin release - functional requirements proposed list
- #4: USE CASE DEFINITIONS - The team can then use the Use Case Template to team fill out more details about the Template detailing their Use Case. The use Case Template can be found here: 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. A project submission, the intention to participate is announced. The TSC reviews and provides its gives disposition on all submitted projects proposal. In Project Planning closure, the submissions from all of the new projects have been submitted in wiki their Release Planning materials. These are also tracked on the Release Planning page.
- 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.
M1
- USE CASE TEAMS - The Use Case Teams prepare their proposals. At M1 the project submission, proposal and planning have occurred with the TSC. Use Case teams are cross-functional in nature: they are composed of a leader, developers and also (indirectly) the ONAP platform members from components that need to be involved. Working towards M1, the Use case teams are defining their requirements and starting to craft a Data Model.
- #1 RELEASE PLANNING TEMPLATE - 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 contains a master blueprint of all of the major areas of a use case that need to be tracked. The Use Case teams should discuss and fill out for themselves this milestone checklist, and particularly, the product management and release management sections. The major topic areas of the checklist are: documentation, security, product management, release management, testing & integration and development. 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 SYNC - The model subcommittee team should become aware of the use cases for the current release. Use Case teams are expected to make presentations to the modeling sub-committee for use cases that may impact the information model. This should open a dialogue between the Use Case team and the modeling to identify model impacts and where there might conceptual overlaps to help streamline the design. The Use Case teams may also be agnostic to the broader information model and contact between the modeling sub-committee and the use case teams will also raise awareness of relevant information models that the Use Case teams will need.
- #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. The Use case teams should be identifying three things which will help the Modeling subcommittee understand better the model impacts. This will help the modeling team identify areas where model impacts will be. The Use Case teams should define their use cases in more detail ideally using the inputs, outputs and data flows.
- PRECONDITIONS - Preconditions are the Information the use cases consume.
- POST-CONDITIONS - The post-conditions can capture the kind of information that is output from the use cases.
- INFORMATION EXCHANGES - information exchanges capture the type of information that passes from component to component, APIs, NBI and external interfaces. This helps to identify the relevant models that give that exchanged information structure
- 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 Architecture Meeting Notes (New)
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.
WIKI LINKS References for the Use Case Teams at M1
The following are from the Deliverables for Planning Milestone Checklist Template
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 6 Architecture Component Descriptions ONAP Architecture Component Description - Guilin (R7) Release
- 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.
- #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 -
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
- CONSIDER CONTRIBUTION - START: Input Contribution (verb Consider) END: Contribution in Discussion State
- ARCHITECTURE SUBCOMMITTEE leading up to M2 -
- 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.
- #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.
- Architecture - Every release, the architecture sub-committee refines the functional architecture, creates new flow updates, and may update component architectures.
- #1: SOCIALIZATION - The Use Case teams should become aware of the new functional architecture and component architecture changes for the current release. Architecture should become aware of new modeling concepts. Cross-fertilization of new requirements, use cases and how they might impact model or how the model impact the upcoming proposed architecture changes. The idea is that the use case leads would queue some time in one of the architecture S/C calls (as a 1-off) to discuss the use cases that may impact platform components for that release. The Use case teams can reserve some time on the Architecture sub-committee team meeting to align the use cases with the architecture. The Architecture lead (PTL) can also flag impacts of the functional architecture to use cases and vice versa.
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.
- 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.
- TERMS & CONCEPTS -
- IISOMI STATES - The concept of IISOMI states describes the state of individual classes, attributes, and associations/relationships. IISOMI states are noted within the elements of the contribution. For example, a particular parameter might be in the experimental state while another class might be tagged as in the preliminary state. These preliminary and experimental are states that are mutually exclusive so you can't have a class/attributes with two different IISOMI states simultaneously. During the discussion phase, the elements of the contribution should be out of experimental state. The exception is that there is a state of reference that can exist with other states. Some elements within the contribution could have different IISOMI states. The webpage for the IISOMI states can be found at: Informal Inter-SDO Open Model Initiative (IISOMI)
- DELAYED ELEMENTS OF THE RELEASE INFO-MODEL - This may happen that are out of the control the modeling S/C. Use Cases get delayed, or a discussion can't wrap up. So, there could be a corner case where, for example, one or more things (parameters/classes) in a contribution can't make the current release (it stay experimental), what would happen to the overall contribution or release information model (is it allowed to go clean). This would not stop the other parts of the contribution or the release information model from going to a clean state. #@# Example, Dynamic parameters in the common sub-model, generates the whole model then manually edited down to the DP. if things are marked experimental it will show experimental. Keep of Track (experimental?) communicate? reviews?
- 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
- (a) FINAL PRESENTATION - When the contribution has gotten to a point where the team feels that it can start to undergo the approval process, the contribution is brought one final time the modeling S/C for discussion and socialization.
- (b) FINAL CALL FOR COMMENTS - After that, a final call for comments is issued by a sub-team lead to the modeling team whereby final thoughts & input can be given. This final call for comments signals that the discussion is wrapping up for this contribution and will soon go to a poll.
- (c) INITIATING POLL - After final call and no further outstanding comments exist, the contribution is brought to a poll by a sub-committee chair. A poll is created whereby modeling S/C members can give the contribution a vote of "yes" or "no".
- 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.
- STEREOTYPE CHECK - The entities in the model has an experimental stereotype (down to the attribute level) when they are a proposal, when approved/clean, all of the entities in that proposal bear change from experimental to preliminary. Stereotypes can be on classes, attributes, data types and relationships. It is an ISOMII add into the model, at a high-level in the model things get stereotypes. E.g. when we approved the first VES model, which has many entities and many attributes; to update all of those from experimental to preliminary was tough. A stereotype is a status marker. Preliminary is approved for development.
- CONSIDER CONTRIBUTION - START: Input Contribution (verb Consider) END: Contribution in Discussion State
M2
- Architecture Engagement -
- M2 ARCHITECTURE WORK - Before M2, the architecture team is working to refine their Functional Architecture, the component architecture, and Architecture proposed enhancements. Conceptually, many would consider the development of the release information model as actually architecture work. Thus, engaging the actual architecture sub-committee during the point in the time that the release information model is becoming frozen is important.
- SYNC UP - The architecture sub-committee should have a sync up with the modeling sub-committee to have a check-point to share the release information model. The key triggering milestone is that the release information model has just achieved a clean state, and the architecture sub-committee should be aware of this, and some of the highlights in the model. For example, the key contributions in the release that comprise the model. The modeling sub-committee should get on the agenda of the architecture S/C or vice versa when the release information model is ready. Alternatively, a regular sync up with the architecture sub-committee, such as once a quarter or bi-annually could also serve this purpose.
- Components (PTL) Engagement - ONAP Platform Teams (A&AI, SO, SDC etc) review clean Information Model impacts for the release.
- FEEDBACK - Component platform work can feedback to the Modeling S/C for updates to the information model during the refining the info model phase and should also provide input during the review. Modeling S/C should take into account component platform updates vis-a-vis the Use Case and modeling requirements for the release.
- SOCIALIZATION - The socialization of the clean release information model should include updates for the PTLs. The platform PTLs must become aware that the clean release information model has gone to approval. The PTLs also attend the TSC. An email to the PTLs. Possibly a joint call with the PTLs in attendance might help to socialize the information model. Because this is a major milestone of the modeling S/C. Perhaps a modeling notification email distribution list could be made that would send major updates from the modeling S/C and that would not flood notifications from the modeling team. An email announcement of polls, in this case the baseline of a clean release information model.
M2 CHECKPOINTS & COLLABORATION
- Components (PTL) Engagement - ONAP Platform Teams (A&AI, SO, SDC etc) review clean Information Model impacts for the release.
- FEEDBACK - Component platform work can feedback to the Modeling S/C for updates to the information model during the refining the info model phase and should also provide input during the review. Modeling S/C should take into account component platform updates vis-a-vis the Use Case and modeling requirements for the release.
- SOCIALIZATION - The socialization of the clean release information model should include updates for the PTLs. The platform PTLs must become aware that the clean release information model has gone to approval. The PTLs also attend the TSC. An email to the PTLs. Possibly a joint call with the PTLs in attendance might help to socialize the information model. Because this is a major milestone of the modeling S/C. Perhaps a modeling notification email distribution list could be made that would send major updates from the modeling S/C and that would not flood notifications from the modeling team. An email announcement of polls, in this case the baseline of a clean release information model.
- #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. For example, the R7 Component Wiki Page is at: ONAP Architecture Component Description - Guilin-R7
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 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. Use a Blue Lollipop to represent a Consumed API, a Beige Lollipop to represent an offered API and add a Legend to your Draw.io diagram showing these.
COLOR MEANING Status colour Yellow title RED Offered API Status colour Blue title BLUE Consumed API Legend
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...
Component Description Updates Each of the PTLs for a component need to update the general descriptions of their component on their respective component page.
Generally this will not change much with each release, but updates reflecting the changes in that release should be described.
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
- Use Case Engagement -
- API Freeze - M3 is characterized by the API freeze. The main thing that happens at M3, the API is frozen by the Use Case Teams.
- Data Model Freeze - Developers identify a problem in the data model which affects the information model.
- SYNC UP - since the Modeling S/C is familiar with the info-model; the Use Case Teams should present at the Modeling S/C their proposed data model that might be frozen so that the modeling S/C can assess it to see if might have impact to the Info-model. There should be some collaboration or check-point at M3 to discuss and potential ripple affects back to the information model.
- DATA MODEL IMPACTING INFO MODEL - If changes in the Data Model impact the information model, those changes need to be worked by the model S/C. The Modeling S/C would evaluate the change to the Information model and possibly make updates.
- USE CASE TEAMS INDICATE CHANGE - The Use Case teams may have enough knowledge of the info-model that they identify a data model change that may impact the information model. This presumes that the use case teams know that their changes in a data model may have impact to the information model.B
- CONSIDER DATA MODEL - START: Input Data Model > verb Consider > END: Data Model in Discussion State
- The data model is a model that is used in a Use Case and is based on the Information Model. It is generally a self-contained model which depicts a particular capability or function of the system. The data model starts as a "input data model" and undergoes consideration by the Use Case teams. Consideration means that the Use Case teams is entertains & assesses if the input data model. If the Use Case teams think that the contribution is not ready for the current release that contribution it might postponed. It would be noted in the Release Management Project page as such.
- REVIEW & REFINE CONTRIBUTION - START: Data Model in Discussion State > verb Reviewing & Refine > END: Data Model in Discussion state
- The data model undergoes reviewing & refining during the discussion state. Reviewing & refining means that the Use Case Teams are discussing the data model and updating their data model based on feedback and comments from the Use Case team and modeling team. Each data model can be reviewed and refined independently and concurrently with other use case projects. Things in the discussion state are classes, attributes and relationships are tagged as IISOMI experimental.
- MODELING S/C ENGAGEMENT - The Use Case teams may wish to solicit the opinion of the modeling S/C and present their data model for discussion and socialization.
- FINAL CALL FOR COMMENTS & INITIATE POLLING - START: Data Model in Discussion State > verb Approving/Poll > END: Data Model in Discussion state
- (a) FINAL PRESENTATION - When the data model has gotten to a point where the use case team feels that it can start to undergo the approval process, the data model is brought one final time the use case team.
- (b) FINAL CALL FOR COMMENTS - After that, a final call for comments is issued by a use case lead to the modeling team whereby final thoughts & input can be given. This final call for comments signals that the discussion is wrapping up for this contribution and will soon go to a poll.
- (c) INITIATING POLL - After final call and no further outstanding comments exist, the contribution is brought to a poll by a use case lead. A poll is created whereby use case team members can give the contribution a vote of "yes" or "no".
- APPROVING CONTRIBUTION - START: Data model is in Discussion State Post-Poll > verb Approving > Data model in Clean State
- After the poll has concluded, the data model has finished the approval process. The data model 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. #@# do data models also use ISOMII states?
- Component Data Model Final - x.
- RECONCILE - Reconciling the info-model with the data-model. M3 checklist. (API Freeze)
- M3 CHECKLIST - The M3 check list is used. This is a vehicle to engage the Use Case (project teams) and reconcile the Use Case Teams with the modeling S/C team's work. The Check list can be found here: Proposed M3 Checklist modeling updates discussion
- 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. This means that certain elements within the model(s) could go to back to an experimental state. Note that only certain elements (e.g. attributes, ranges) are likely to go to the experimental state NOT the entire contribution. More often though, new additions could be added to a contribution model. In general, there would likely be just minor tweaks on the model. So when a contribution is clean it has to be at least preliminary. A contribution cannot be clean and experimental. Clean has a relationship to the IISOMI states. For an entity to be clean it must be either preliminary or mature (see the IISOMI state diagram link).
- IISOMI STATES - A link to the IISOMI state diagram can be found here: Stereotypes
- NEW ADDITIONS - A contribution model could be clean, but things added afterwards and those elements would come in as experimental.
- STILL IN PROGRESS ITEMS IN RELEASE INFO MODEL - It is possible that as the modeling team enters the M3 milestone that there are still some things in progress, that are expected to be in the current release. They might still be marked experimental even though the release information model is clean. Thus, to open item are continue to be work; and it is expected it would not affect software if code were already associated to it.
- ITEMS IN DISCUSSION - e.g. when root contribution was done, with root party is an example as it was not agreed to, we made the decision to leave that experimental until a future date. There were aspects agreed, and other things left experimental to pursue in the future. The main contribution was split. These parts everyone agreed with and these part left experimental which would be taken up in a future contribution and re-discussed. This would likely occur at M2, and they might be discussed at M3. There was a conscious decision and agreement by the modeling team that the parts of the model still open would be pushed to the next release. So only theoretical discussion would happen at this point of how to proceed in the future release.
- FUTURE WORK - Things originally planned to be in a release could potentially transform into future work items. Some modeling work could be pushed to the next release if need be, if it is decided that it could not be completed in the current release.
FUTURE WORK- Future work is typically identified as such at the start of a release at M0 in the release modeling planning page. Future Work can still proceed. For example, in R6 the geo-location modeling work is not tied to any active development yet. The location work is a good example of work that was worked in ADVANCE of when it is expected to be used (Future Work). It is also possible that some of the future work is building upon a foundation of work that had already been started (or was looked at) or implemented in a prior release. - DEFER WORK - It might be decided the the future work could be deferred to the next release. On the current modeling high level requirements page to indicate that a particular future work has been deferred to a future release. In order not to lose the activity, it would be expected that it would be rolled into the next release's Modeling High-Level Requirements.
- CONTINUE WORK - Future Model work may continue to proceed in the current release..
- M3 CHECKLIST - The M3 check list modeling updates discussion is used by the modeling sub-committee. It is used as a vehicle to engage the Use Case (project teams) and reconcile the Use Case Teams with the modeling S/C team's work. See also the Use Case Team Engagement (section below). The Check list can be found here: Proposed M3 Checklist modeling updates discussion
- 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. This means that certain elements within the model(s) could go to back to an experimental state. Note that only certain elements (e.g. attributes, ranges) are likely to go to the experimental state NOT the entire contribution. More often though, new additions could be added to a contribution model. In general, there would likely be just minor tweaks on the model. So when a contribution is clean it has to be at least preliminary. A contribution cannot be clean and experimental. Clean has a relationship to the IISOMI states. For an entity to be clean it must be either preliminary or mature (see the IISOMI state diagram link).
- Architecture Engagement -
- S-P - B-
- Components (PTL) Engagement -
- ARCHITECTURE SUBCOMMITTEE M3 -
M4
Code Freeze
Kickoff Information Model Requirements for Next Release
- READ THE DOCS - (M3 or M4?) The model editor provides a final gendoc word document which serves as the basis for what will be incorporated into the readthedocs. The read the docs can be found here: https://onap.readthedocs.io/en/latest/index.html . The word document is fed into some tools which generates the readthedocs output. The gerrit master model is periodically updated, and a snapshot of the eclipse/papryus model is taken and that is called the release model.
- DOCUMENT GENERATION - The RST documentation that only contains things in the current release or everything that is approved.
- PAPYRUS GENERATION - The Papyrus snapshot is generated. The RST document is created. The readthedocs documentation is generated.
- Note that the papyrus model includes what was/had accepted into the previous release and also anything that is still a work in progress.
- Architecture Engagement -
- S-P - B-
- Use Case Engagement -
- D-T - D-p.
- Components (PTL) Engagement -
RCx
Runtime Compliance
Observations
Establishes and Evolves a Common Model
Project (Component) Team Involvement in Modeling Solution
Governance of Common Model and Corresponding Component Models
- Update possible in M3 and M4 (bug fixes) per exception process
Artifacts
Information Model Artifact Contains
Classes
Relationships with Multiplicity
Important Attributes with Multiplicity
Definitions
Data Types
Feed to Data Dictionary
Tooling - Papyrus with GitHub
Component Data Model Artifacts (Implementation Specific)
Component Data Model
Contains objects, attributes, & relationships (more detail than information model)
Mapping to Information Model
Feed to Data Dictionary?
API Artifacts
API Model
Mapping to Information Model
New Roles – Model Governance
Information Model
Internal Committers
Internal Approvers
Impacted Project (Component) Approvers
Impacted API Approvers
Architecture Group Approvers
Component Data Models
Internal Committers
Modeling Team Approvers
Architecture Approvers
Impacted API Approvers
API Definitions
Modeling Team Approvers
Impacted Project (Component) Approvers
Architecture Approvers
Benefits
Establishment and Evolution of a Common Model (Model Consistency)
Continue Move Toward a Model Driven Design
Improve Data Quality
Modeling S/C, Use Case Team and Architecture team touch points, interactions and cooperation:
SUPPORTING DOCUMENTS
- , 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.
- ARCHITECTURE SUBCOMMITTEE M4 -
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 SUBCOMMITTEE at RC0/RC1/RC2 -
ARCHITECTURE ARTIFACTS
The following summarizes the artifacts of the Architecture Subcommittee
Topic Description Functional Architecture The following diagram is an example of the functional architecture:
This is one of the main outputs of the Architecture Sub-committee.
Component Architectures The component architecture pages capture the architecture per component.
The R7 component wikis can be found here:
ONAP Architecture Component Description - Guilin-R7
Architecture Portal Page The Architecture Portal page can be found here:
https://safratech.net/onapdocs/
The page looks like this:
ROLES – ARCHITECTURE SUB-COMMITTEE
The following table shows some of the key roles within the Architecture Sub-committee
Role Description Chair The Architecture Chair coordinates the Architecture work and sets a vision for the sub-committee. Members Members of the Architecture are involved in architecture activities and reviews
SUPPORTING LINKS & DOCUMENTS
DOC | FILE / WIKI |
---|---|
Use Case Way of Working | |
Modeling WoW | Proposed ONAP Release Process Updates for Information and Data Modeling |