“ONAP provides a comprehensive platform for real-time, policy-driven orchestration and automation of physical and virtual network functions that will enable software, network, IT and cloud providers and developers to rapidly automate new services and support complete lifecycle management.
By unifying member resources, ONAP is accelerating the development of a vibrant ecosystem around a globally shared architecture and implementation for network automation–with an open standards focus–faster than any one product could on its own.”
Part of the ONAP charter from onap.org.
The ONAP project is gaining attention in service provider circles. The Steering Committee of the ONAP project hints at the types of organisations investing in the project. The statement above summarises the mission of this important project. You can bet that the mission has been carefully crafted. As such, one can assume that it represents what these important stakeholders jointly agree to be the future needs of their OSS.
I find it interesting that there are quite a few technical terms (eg policy-driven orchestration) in the mission statement, terms that tend to pre-empt the solution. However, I don’t feel that pre-emptive technical solutions are the real mission, so I’m going to try to reverse-engineer the statement into business needs. Hopefully the business needs (the “why? why? why?” column below) articulates a set of questions / needs that all OSS can work to, as opposed to replicating the technical approach that underpins ONAP.
| Phrase | Interpretation | Why? Why? Why? |
| real-time | The ability to make instantaneous decisions | Why1: To adapt to changing conditions Why2: To take advantage of fleeting opportunities or resolve threats Why 3: To optimise key business metrics such as financials Why 4: As CSPs are under increasing pressure from shareholders to deliver on key metrics |
| policy-driven orchestration | To use policies to increase the repeatability of key operational processes | Why 1: Repeatability provides the opportunity to improve efficiency, quality and performance Why 2: Allows an operator to service more customers at less expense Why 3: Improves corporate profitability and customer perceptions Why 4: As CSPs are under increasing pressure from shareholders to deliver on key metrics |
| policy-driven automation | To use policies to increase the amount of automation that can be applied to key operational processes | Why 1: Automated processes provide the opportunity to improve efficiency, quality and performance Why 2: Allows an operator to service more customers at less expense Why 3: Improves corporate profitability and customer perceptions |
| physical and virtual network functions | Our networks will continue to consist of physical devices, but we will increasingly introduce virtualised functionality | Why 1: Physical devices will continue to exist into the foreseeable future but virtualisation represents an exciting approach into the future Why 2: Virtual entities are easier to activate and manage (assuming sufficient capacity exists) Why 3: Physical equipment supply, build, deploy and test cycles are much longer and labour intensive Why 4: Virtual assets are more flexible, faster and cheaper to commission Why 5: Customer services can be turned up faster and cheaper |
| software, network, IT and cloud providers and developers | With this increase in virtualisation, we find an increasingly large and diverse array of suppliers contributing to our value-chain. These suppliers contribute via software, network equipment, IT functions and cloud resources | Why 1: CSPs can access innovation and efficiency occurring outside their own organisation Why 2: CSPs can leverage the opportunities those innovations provide Why 3: CSPs can deliver more attractive offers to customers Why 4: Key metrics such as profitability and customer satisfaction are enhanced |
| rapidly automate new services | We want the flexibility to introduce new products and services far faster than we do today | Why 1: CSPs can deliver more attractive offers to customers faster than competitors Why 2: Key metrics such as market share, profitability and customer satisfaction are enhanced as well as improved cashflow |
| support complete lifecycle management | The components that make up our value-chain are changing and evolving so quickly that we need to cope with these changes without impacting customers across any of their interactions with their service | Why 1: Customer satisfaction is a key metric and a customer’s experience spans the entire lifecyle of their service. Why 2: CSPs don’t want customers to churn to competitors Why 3: Key metrics such as market share, profitability and customer satisfaction are enhanced |
| unifying member resources | To reduce the amount of duplicated and under-synchronised development currently being done by the member bodies of ONAP | Why 1: Collaboration and sharing reduces the effort each member body must dedicate to their OSS Why 2: A reduced resource pool is required Why 3: Costs can be reduced whilst still achieving a required level of outcome from OSS |
| vibrant ecosystem | To increase the level of supplier interchangability | Why 1: To reduce dependence on any supplier/s Why 2: To improve competition between suppliers Why 3: Lower prices, greater choice and greater innovation tend to flourish in competitive environments Why 4: CSPs, as customers of the suppliers, benefit |
| globally shared architecture | To make networks, services and support systems easier to interconnect across the global communications network | Why 1: Collaboration on common standards reduces the integration effort between each member at points of interconnect Why 2: A reduced resource pool is required Why 3: Costs can be reduced whilst still achieving interconnection benefits |
As indicated in earlier posts, ONAP is an exciting initiative for the CSP industry for a number of reasons. My fear for ONAP is that it becomes such a behemoth of technical complexity that it becomes too unwieldy for use by any of the member bodies. I use the analogy of ATM versus Ethernet here, where ONAP is equivalent to ATM in power and complexity. The question is whether there’s an Ethernet answer to the whys that ONAP is trying to solve.
I’d love to hear your thoughts.
(BTW. I’m not saying that the technologies the ONAP team is investigating are the wrong ones. Far from it. I just find it interesting that the mission is starting with a technical direction in mind. I see parallels with the OSS radar analogy.)
Standing out in a highly saturated and fragmented OSS market can be really difficult. We’re regularly involved in bake-offs where we see dozens of OSS
One of the things I love about my job is all the vendor demos I get to see. Product demos are one of the four
Have you read the book, “The 4-hour work week” by Tim Ferris? It was one of those relatively rare books that inspired a complete mindset
Over the years, we’ve been involved in many OSS procurement events and have seen a variety of different pricing models proposed by vendors. Being software,
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
