The following diagram illustrates the overall Modeling process:

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

The following diagram shows the modeling process in more detail:

Proposed ONAP Process Improvements

• No Modeling Presence

  • Add Modeling Swim Lane

  • Add Modeling Artifacts for appropriate milestones to Modeling Swim Lane

• MO

  • Only Item in M0 timeframe is “Open Intent To Participate”

  • Modeling team has two categories of “High Level Info-model Requirements”
    • #1: items from the expected Use Cases in the release (Scope of modeling, continuing, introducing, standards updates).
    • #2 there are also Existing high level info-model requirements that need to be worked on and also requirements that we know are coming.
  • Use Case Team (evaluating U/C proposals) present 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.
  • 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

  • Project Planning / Functional Architecture Defined / Architecture Approved

  • Add “Infomodel Plan Established”

  • Note:  Infomodel Updates Begin / Data Model Refinements Begin (M1.5)

  • Note:  Development Commitments for Infomodel Requirements?

• M2

  • Functionality Freeze

  • Add “Infomodel Freeze” (Approval)

  • Add “Data Model Freeze” (Approval)

  • Note:  Feed to Data Dictionary??

• M3

  • API Freeze

  • Add “Infomodel Final”

  • 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