The following diagram illustrates the overall Modeling process.

it shows the basic stages of a release, going from M0 (release kickoff) through M3 (API Freeze).

it illustrates 5 stages that the Modeling team is concerned with, the High Level model requirements, to the model plan work, to refining the information model, to model launch and then to model freeze.

The following diagram shows the Information and Data Model co-evolution and interaction flow:

There are three tracks one for the modeling S/C, the Use Case teams, and for API.

The modeling S/C before M0 kickoff, it working to define the high level information model requirements, then creating the input model before M1.

After M1, the modeling S/C works to refine the information model leading up to M2, and then the model is frozen going into M2.

After the model is launched, and frozen, the clean model can potentially be tweaks if necessary from refinements or updates from the use case teams.

Meanwhile, the Use Case teams are creating a Data Model which is based on the information model.

The data model also goes through four phases, from initial requirements assessment, to input data model, discussion data model, and finally the clean data model.

The clean data model serves as input to create the API.

The following diagram shows the modeling process in more detail:

Modeling Sub-Committee Process

• MO

  • Modeling team 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).
    • #2: REFINING EXISTING MODEL - There are also Existing high level info-model requirements and the current release is focused on continuing or refining the model. Existing in a component that hasn't made it to the information model. Previously at design build-level that needs to be added into information model. For example, a need might have arisen in development but wasn't formalized. Long-lead, multi-release items might fall into this category. coded previously but no Use Case.
    • #3: FORWARD LOOKING WORK (FLW) - Forward thinking requirement. For example, suppose there were a very large use case/requirement or project that is expected to come down the pipe, but if no advanced modeling work were done on it, it wouldn't make the current release. Thus, a model might be proposed in advance of the actual use case/requirement.
  • Use Case Team (evaluating U/C proposals) presents their modeling needs. Each of the Use Case teams needs to come to the modeling S/C meetings to present their expected modeling needs and open a dialogue about potential model impacts so that they can be developed. Describing the the pre/post conditions, defining the overall definition.
  • Architecture understanding reference model. Modeling S/C members should be aware of any updates to the current release's reference model so that potential can be known.
  • PTL - High level release scope from PTLs (understand from ONAP components what updates)
  • PTL - Joint PTL sync meeting

• M1

  • 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: MODELING REQUIREMENTS - A description of each of the modeling requirements are described in more detail. This can be contributed from the modeling team, PTLs or the Use Case teams.
    • #2: USE CASE RELEVANCE - The relevance of use cases are identified and Use Case teams can give a more detailed explanation for use case requirements and how they tie to the high-level requirements. This allows for experts in the Info-model team to identify what fields of the existing info model could be enhanced and become aware of where the impacts are. 
    • #3: IMPACTED PROJECTS - The impacted projects from the info-model requirements (e.g. SO, VID, SDC etc) are identified. The tie-in from the ONAP platform components to the high level-modeling requirements are described.
    • #4: OVERLAPPING PROPOSALS - Overlapping info-model impacts from different use cases or forward looking work (FLW) are identified.
    • #5: MODEL REUSE - Finding Overlap from different use case and requirement proposals that are evaluated will lead to identifying where model reuse can occur. By the end of the Model overlap analysis overlapping areas will either cause overlaps to be merged or altered.
    • #6: OWNER - The owner(s) for the item are identified. The owners might be PTLs, Modeling subcommittee, or Use Case team.
    • #7: PRIORITY - A priority is identified for the info model requirements. these are general given by service providers or modeling subcommittee. A suggested High/Medium/Low is sufficient at this stage.
    • #8: LOWER PRIORITY - Lower priority requirements are generally considered as "nice to haves". Low priority requirements are captured in the info-model plan and are documented.
    • #9: DOCUMENTATION AFTER IMPLEMENTATION - Some modeling requirements are related to documenting implementation after the fact. When the model plan is established, this category of info-model requirements are identified and described in the info-model plan.
    • #10: FORWARD LOOKING WORK (FLW) - FLW is another class of requirements which are intended to recognize future needs.
      
  • Use Case - 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: SOCIALIZATION - The model 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.
    • #2: DATA MODEL - 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 kind of information shown in this template: Proposed Functional Template for Use Cases
      
      • PRECONDITIONS - Preconditions are the Information the use cases consume.
      • POSTCONDITIONS - 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
  • Architecture - Every release, the architecture sub-committee refines the functional architecture, creates new flow updates, and may update component architectures.
    
    • #1: SOCIALIZATION - Modeling team becomes 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 modeling S/C leads would queue some time in one of the architecture S/C calls (as a 1-off) to discuss the information model for that release and vice versa. Another possibility would be to reserve some time on the Architecture sub-committee call either on a regular basis or when the modeling S/C team is about to accomplish an objective, or about to make a vote on something (to call for consensus). It would also be good if the Architecture lead (PTL) could identify modeling impacts and flag them as they come across them.
  • Components (PTL) - Each of the ONAP platform components (e.g. A&AI, SO, Controllers, SDC etc) may be impacted by new modeling changes and new use cases. Having the modeling S/C engage PTLs (or vice versa).
    
    • #1: COMMITMENT & TRACKING - The data model eventually serves as the basis for API changes and development. 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).
      

• M2

  • Modeling SubCommittee -
  • For each contribution
    
    • PHASE 1: CONSIDERING - 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 XYZ happens.
    • PHASE 2a: REVIEW & REFINE - 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.
    • PHASE 2b: APPROVING - 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 socialization.
      • (b) FINAL CALL - 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 signals that the discussion is wrapping up for this contribution and will so go to a poll.
      • (c) POLL CREATED - 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 members can give the contribution a vote of "yes" or "no". 
    • PHASE 3: APPROVING - START: Contribution in Discussion State (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.

• PHASE 6: Contribution Model (verb Conjoined) Information Model (Frozen)
  
  • REFINING INFORMATION MODEL - The information model that has been scheduled for development from the model requirements planning is being developed and refined in this phase of work. The various models and components of the information model are discussed are refined week to week with input from model sub-committee members. Following IISOMI, The classes & attributes are all in experimental state. The model has been posted.
  • DISCUSSION INFO MODEL - In this phase, during the refining of the information model by the Modeling Sub-committee (S/C) a given contribution is in "Discussion Information model" state. The proposed contribution would be put in the discussion section of the Modeling S/C wiki for a particular release. For example, for R6 (Frankfurt) for the service model there would be an input model, discussion model and a clean model sections. As the contribution is worked on, it would move from the input to the discussion to the clean model sections. The following key concepts will be used to describe how the contributions are handled and the various states that are used to track their development:
    • IISOMI STATES - The concept of IISOMI states describe 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 preliminary. 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.  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)
    • CONTRIBUTIONS vs RELEASE - Parameter group (R7) refinements some things still as "preliminary" (accepted) but a few new ones are "experimental" than the contribution becomes clean. Just because the contribution is clean, does not mean the release has gone to clean.
    • MODELING S/C STATES - Input / Discussion / Clean states.
  • INFORMATION MODEL REVIEW - After the discussion information model has been refined, a particular contribution will undergo review by the modeling sub-committee et al. People can comment on the wiki and there will generally be a face-to-face review as well. Objections and continued discussion can be accommodated for with further discussions and responses in the wiki page.
  • INFORMATION MODEL FREEZE - The information model for the release is approved after it has been review by the modeling sub-committee. Note: even after the freeze, some minor refinement can still occur (see the M3 activities).
  • CLEAN INFO MODEL - After review and 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.
• Architecture Engagement -
  • SYNC UP - Before M2, the architecture team is working to refine their Functional Architecture, the component architecture, and Architecture proposed enhancements.
• Use Case Engagement -
  • DATA MODEL DEVELOPMENT - Discussion Info Model & Data model development with input from the Model S/C. 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.
  • DATA MODEL REVIEW - Reviews of Data Model with Project Teams. The Data Model is being reviewed by the Use Case Teams with inputs from the Modeling S/C
  • JOINT REVIEWS - The Data model should be reviewed with the Modeling S/C.
• 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.

• M3

  • API Freeze

  • Add “Infomodel Final”

  • Add “Data Model Freeze” (Approval)

  • Add “Component Data Model Final” (Approval – Design Level Compliance)

• M4

  • Code Freeze

  • Kickoff Information Model Requirements for Next Release

• 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