Effective CSP NaaS Solution Development Starts Internally

Recently, I had the opportunity to attend this year’s FutureNet World event in London and speak on a panel: Network as a Service and Automation Use Cases for Communications Service Providers. I enjoyed the opportunity to speak with networking innovators in the SP space, and the experience helped confirm my assessment of how service providers must adapt to the new networking landscape.

Service providers find themselves in an increasingly competitive and challenging environment. The good news is, traffic on their networks continues to grow year over year. The bad news is, they’re challenged with scaling their infrastructure to stay ahead of that growing demand in the fastest, most cost-effective way. And even though traffic is growing, revenue is not growing at anywhere near the same rate.

On top of all that, hyperscalers have entered the market and are using their own cloud-centric operating model to introduce new competing services and generate their own revenue streams. In many cases, service providers are losing out on the most profitable services to these over-the-top (OTT) players.

To stay competitive and profitable in this new environment, many providers are looking at Networking as a Service (NaaS) to innovate faster and further monetize their networks. NaaS can offer new revenue opportunities, provide a faster return on network investment, simplify the consumption of network services, and lower the cost of implementing those services. What many providers are discovering, however, is that delivering NaaS is vastly different from their current operating models. Beyond that, many providers simply don’t have the basic capabilities to expose their network capabilities as NaaS services.

Despite those challenges, NaaS — when implemented the right way — can offer service providers a compelling way to offer new solutions and use cases.

Building an Internal Sandbox

For service providers looking to explore a NaaS solution, there are a number of questions to ask and things to consider.

First, is defining what NaaS actually entails and how a service provider can implement it. One operator’s NaaS requirements may be different from those of another operator. Along with that, what type of NaaS service will customers be willing to pay for? What would make it a commercially viable solution?

Also, what type of NaaS consumption model does the operator want to explore? Will they offer an external solution, an internal solution, or a combination of the two?

Other considerations are:

• How do users discover services?
• How do we charge for services? Is it a usage model?
• How do we enable users to track their consumption?
• How do users order and change services?
• How do we track deployed services and manage service quality?
• How do users test and resolve issues?

It can become very complicated very quickly.

Many providers, wisely, are taking a very methodical and deliberate approach to exploring NaaS and gaining the expertise necessary to eventually offer a commercial service. Jumping right into offering an external NaaS solution to customers can be a very complicated process, especially if the operator doesn’t have any orchestration or automation infrastructure. And the investment involved can make an operator think twice about taking that plunge.

A better alternative for operators considering embarking on a large-scale NaaS initiative would be to look internally first, using an internal offering and their own internal customers as the proving ground for their proposed NaaS model.

Using an internal solution as a provider’s “sandbox” provides a great deal of flexibility. They can plan their NaaS approach, put together the service composition, and gain the technical and operational experience they need to prove out their model in a less commercially risky way. A service provider’s internal offerings, systems, and customer base — while just as important as their external opportunities — are an easily accessible laboratory to define what a NaaS offering could look like, how users will consume it, how to make it operational, and all the other pieces to make a NaaS offering consumable and commercial externally.

Keeping the process in-house can also be less of a financial risk compared to developing an external offering. Internal cost allocation and control tend to be more flexible and easier to absorb as you develop your NaaS solution. In addition, starting with an internal NaaS solution can also give the provider insights into some commercial opportunities they may not have already thought about.

Look Inside to Look Ahead

Taking the industry’s old monolithic model for product development and applying it to NaaS development probably won’t be successful. But by looking inward first, an operator can gain the expertise and develop the necessary functionality to offer a NaaS solution in a way that doesn’t require a massive investment of time or money, and that can minimize some of the risks involved in focusing on an external solution first.

Working with an experienced partner like Itential that can provide a flexible framework for designing and deploying NaaS services is critical too. Itential has worked with multiple service providers to enable NaaS services by utilizing the Itential Automation Platform’s rapid integration capabilities, no-code design environment, and robust API exposure model. With Itential, teams have been able to transform existing manually configured services into production NaaS API-driven services in as little as three months.

If you’d like some additional context around NaaS for service providers, from myself and from other leading thinkers in service provider networking, you can watch the full panel from FutureNet World on-demand here.