ONAP consumption models whitepaper - Consumption model section

Section 3 of white paper :

Consumption Model

Section Contributors : AT&T (Brian Freeman, Scott Blandford ), Bell Canada (Marc-Alexandre Choquette), Vodafone (Atul Purohit), China Mobile (Lei Huang)

From an end user perspective, within the CSP – what are the key considerations, methods for adoption (technical, organizational, operational, etc…)

Reference Models for Consumption

Plan :

• AT&T & Bell to share the model that they are using (Publically sharable), format 1 page bullet points & preferably a diagram (Editable, so that MAC can change as per standard format)
• Vodafone to share the possible variants / models that are there in total (with examples), which will form part of beginning of the section (with a diagram for each option)
• We need within a CSP roles, parts of the organization that will consume ONAP - ops, technical teams etc...and relevance / consideration points for consuming ONAP (here the points can be generic, ONAP can come in to address them)
• China Mobile can help with pros - cons of various models, what works what requires work, various considerations around it
• Anything else ?

We need 2 breakout calls between 4 of us before next meeting i.e. on 19th November. Ideally a 4-5 pager section 3 should be ready (Draft) by then.

Also look for Saad's initial view, useful areas can be incorporated here

• Vodafone to share the possible variants / models that are there in total (with examples), which will form part of beginning of the section (with a diagram for each option)

1. A project like ONAP can be consumed within a CSP in multiple ways -
   1. Build competency & deliver ONAP in-house
   2. Engage with a system integrator / principal who can do it for them
   3. Look for distribution by professional outfits
   4. Look at ONAP as a reference implementation, and choose a partner/vendor which does similar or all of the same functionalities

2. Below table provides pros & cons of each model

   ONAP Consumption Model	Pros	Cons	Examples
   Build competency & deliver ONAP in-house	CSPs are in complete control of the code ONAP out of the box functionality is not suited, CSPs can customize / enhance / change it CSPs becomes more software culture oriented CSPs will have to be much more involved in forum & exchange of information, contributions, involvements increase	Identifying software capabilities & building teams takes time & effort Mind-Set change is the biggest impediment Operating model (in-fact entire organizational construct) needs changing, which may be challenging	AT&T, Bell Canada (any other ?)
   Engage with a System Integrator / Principal Vendor who can do it for them	This is an outsourced model, where an identified System Integrator / Principal Vendor takes the ownership of development, testing & deployment - means CSPs are still in control, but are doing it in a "Delegated" mode Risk of delivery problems reduces, since professional System Integrators / Principal Vendors does "Delivery" for a living, they are more mature by design	CSPs have to keep track of changes, identify possible enhancements, requirements and get them delivered via identified System Integrator / Principal Vendor Complacency may creep in if the "Delegated" partners are doing most of the heavy lifting - CSPs may becomes too dependent	Amdocs, Accenture (any one else ?)
   Look for distribution by professional outfits	Similar to OpenStack distributions which are out there, ONAP can potentially have "Distro" professional outfits - who would provide a hardened (tested, fit for purpose) and well maintained software asset - which can then be - Either be developed in house or An external System Integrator / Principal Vendor can do it for CSPs Or, the "Distro" providing professional outfit can do it as part of their "Professional" services Onus of keeping up with forum's workings, bug fixes in "Productized" version of ONAP etc...can be taken care by "Distribution" Professional Outfit	If chosen delivery option is not the same as the professional outfit, friction in delivery may creep in Wholesome commitment of professional outfit to ONAP may need some monitoring	Aarna Networks ( ?) Anyone else ?
   Look at ONAP as a reference implementation, and choose a partner/vendor which does similar or all of the same functionalities	There are multiple SDOs that ONAP adheres to, For Ex - TMF, 3GPP, ETSI, GSMA etc..., this model absolves CSPs from asking ala-carte SDO compliance to vendors while choosing their products; and instead place ONAP as a reference-able architecture (& for compliance) in front of vendors and get a product that best complies to standards Depending on the chosen vendor, strengths of the vendor and up-keep of the application is complete owned by the vendor	Software culture does not kick in Dependency on vendor still high	Many