...
- A project like ONAP can be consumed within a CSP in multiple ways -
- Build competency & deliver ONAP in-house
- Engage with a system integrator / principal who can do it for them
- Look for distribution by professional outfits
- Look at ONAP as a reference implementation, and choose a partner/vendor which does similar or all of the same functionalities
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
On 4 model diagrams, use a tablet to scribble and create a sketch, we will request MAC artists to help with appropriate diagrams / AP on Atul