Draft Architecture Principles

Architectural principles provide guidelines when making architecture decisions. The principles are not requirements (functional or non-functional), nor should they specify the design of the system.

[ 1 1.Virtualized Software Based Applications ] [ 2 2. Decoupled Applications Modules/Microservices ] [ 3 3. Shared Standard Cloud Platform ] [ 4 4. Software Modularity and Reusability ] [ 5 5. Open Platform and APIs ] [ 6 6. Supplier Agnostic ] [ 7 7. Model-Driven ] [ 8 8. Automation First ] [ 9 9. Full Service Lifecycle Support ] [ 10 10. Agile Development and Operations (CI/CD) ] [ 11 11. Self Service ] [ 12 12. Availability ] [ 13 13. Security ] [ 14 14. Pluggable Dependencies ] [ 15 15. Integration Friendly ] [ 16 16. Policy-Based Decisions ] [ 17 17. Service, resource, function, and business model agnostic ] [ 18 18. User-Focused ] [ 19 19. Common Data Layer and Information Model approach ] [ 20 20. ONAP scaling ] [ 21 21. Multi-tenancy ] [ 22 22. Centralized Design ] [ 23 23. Backward Compatibility ]

1.Virtualized Software Based Applications

Flexibility in component deployment is important to ONAP functionality. All components in ONAP should be virtualized, preferably with support for both virtual machines and containers. All components should be software-based with no dependency on hardware platform. However, where hardware capabilities can enhance an ONAP component, those capabilities can be used if not required for the component to function.

2. Decoupled Applications Modules/Microservices

All components in ONAP should avoid tight coupling between other components. Components should be service-based with clear, concise function addressed by each service, following principles of microservices.

3. Shared Standard Cloud Platform

All components in ONAP should be able to run on a shared standards-based cloud platform. Ideally, the cloud platform implementation should be pluggable and transparent to the ONAP components.

4. Software Modularity and Reusability

Code within ONAP should be designed in a modular fashion & reusability is highly encouraged across components. Where applicable, reusable components can be provided as shared services across ONAP components.

5. Open Platform and APIs

An open, standards-based architecture with well-defined APIs fosters interoperability both within ONAP and across complementary projects and applications.

6. Supplier Agnostic

The ability for ONAP to be used by various users worldwide dictates the need to avoid dependency on any single supplier(s). All efforts within ONAP should be agnostic to a supplier’s function, application, or code.

7. Model-Driven

All aspects of a network service design in ONAP should be model-driven, avoiding, where possible, programming code. This allows for a catalog-based reusable repository for a network service lifecycle.