White Papers

Understanding OPNFV

Issue link: https://read.uberflip.com/i/1344850

Contents of this Issue


Page 129 of 144

Understanding OPNFV 129 committers and contributors. These teams prioritize their own backlog, develop requirements, contribute upstream code if required, develop their own tests, and ensure the readiness of their project for a given release. The technical steering community (TSC), infrastructure, and test projects perform coordination and common activities across OPNFV projects. Users can learn how to organize their teams for successful NFV transformation by getting involved with OPNFV, and model their organizational structure after that of OPNFV. Let's revisit the organizational structure readiness questionnaire from Chapter 2 and see how OPNFV helps: Question Readiness: 1-5 (1 = Not ready, 5 = Completely ready) Why? Has there been any example where cross-functional groups formed teams for new technology? 4 Most teams have broad representation from both users and technology providers. Can you imagine completely autonomous teams per NFV service or component (such as NFVI, VIM, MANO) that own dev, test, release and production? 5 Teams own all aspects. (Production phase is not applicable to OPNFV.) Can you imagine a decentralized decision-making approach where each team, within reason, could make their own technical decisions? 5 This principle is fully incorporated into OPNFV. Each team, within reason, paves their own path. Can you imagine the communication between NFV services teams and the platform team to be completely automated? 4 The interface between OSS/BSS and MANO, and MANO and NFVI/VIM is completely specified through APIs. No human interaction is required. Are there mechanisms to discuss requirements that affect multiple 5 With the TSC, infra and test teams, there are plenty of

Articles in this issue

view archives of White Papers - Understanding OPNFV