1. Architecture Face to Face Planning Meeting ONAP Architecture – Modeling Inter-Relationship Andy Mayer; Deng Hui

2. ONAP Modeling Subcommittee Role
Guide the development ONAP Abstractions and Constructs, and form and document Common Models:
Provide a coherent view of shared information
Identify common abstractions and constructs across ONAP
Capture common terms and definitions with respect to shared information
Help identify unplanned redundancy
Mapping of information to interactions for common interfaces (and microservices) (Joint with Arch)
Identify the primary authority (or Steward) and consumers for each piece of shared information from a functional perspective (Joint with Arch)
Form a common Integrated ONAP Information Model and associated Data Models to be used as an integration resource (Federated approach)
Define Model Versioning Strategy based on ONAP Common Versioning Strategy

3. How do we enable Model Driven ONAP?
Re-Use 3 1
Use Model
Create Model
Common shared data
Functions work off common model
Data translation layer at edge
SDC Environment
Design Models
Design Catalogs
Data Dictionary 2
Deploy Model
Run-time Models
Run-time Catalog
Common Model Parsers

4. Shared Architecture and Modeling Concerns
Enablement of Model Driven ONAP
Common definitions and models of Shared Information (and data models) across APIs and Microservices (Papyrus). Components identify inputs & outputs
Identification of ONAP Components as “Source of Truth” and “Consumers” of Information (wrt ONAP Information Model)
Lifecycle Stages of Information (e.g., On-Board, Design, Instantiate, Operate)
Modeling of containerized VNFs and Multi-cloud requirements
Hybrid Environment (VNFs, PNFs, ANFs)
“ONAP of a Black Box” – Standards at the edges, ONAP inside
ONAP Modularization
Modeling as part of Architectural artifacts (e.g., data models, information models, state models, interaction diagrams, etc.)
Participation of ONAP Components in transitioning to a target state