Cisco’s Latest ESP Evolution = Sixth Sense for NFV Monetization Mandate

Peter Jarich
Peter Jarich

Summary Bullets:

  • Cost efficiencies and support for existing services continue to dominate carrier thinking around SDN and NFV deployment.
  • Monetizing SDN and NFV investments (making money from them), if not top of mind for all carriers, is a priority nevertheless.
  • Going forward, as funding for long-term SDN and NFV transformations continues, monetization will become increasingly important.
  • While many vendors struggle with spelling out solid ways in which NFV can help operators make money from new services, Cisco has managed to provide a few, solid, early examples.

It is not easy to tie NFV directly to new service revenues for carriers.

Trust me on this one; after enough conversations where vendors struggle to explain NFV monetization, I know just how difficult the story is. The link between NFV and CapEx savings is clear, if debatable: think COTS equipment and cheaper functions. The link between NFV and OpEx savings is clear: think new, streamlined operations and service automation. The link between NFV and new service revenues? That one’s a little tougher.

Think about all of the VNFs getting attention today. vIMS might be about supporting VoLTE, but that is not new or in any way impossible without NFV. vEPC or virtual policy implementations are about supporting existing services, too. Service chaining and vCPE offers fall into the same camp. Sure, they are new concepts, but they are not delivering new services. Whether carrier thinking is a result of vendor messaging or vendors are tailoring their messages to what they hear from carriers (chicken meet egg), you see this reality reflected in how carriers think about SDN and NFV business drivers.

Based on our recent survey work, carrier thinking seems to fall into three camps: CapEx and OpEx savings, support for existing services (service scale + service resiliency), and support for new services. It is nice that support for new services was the number one driver for about one-quarter of the service providers we talked to, but that number is dwarfed by those focused on existing services, either just supporting them or supporting them more cost effectively. And yet, going back to my conversations with vendors, this is a major problem for anyone trying to sell NFV or SDN solutions. It is a lot easier for a carrier to justify investing in initiatives that will help them grow their business vs. initiatives that will trim costs… someday. There is a reason why the old saying “you can’t save your way to growth” is a cliché.

This dynamic helps to explain my largely positive take on Cisco’s latest VNF news from this week. Whether or not Cisco has the OSS/BSS assets to pull it off, the concept of leveraging NFV (including specific VNFs and orchestration) to help operators serve a new market (the small business) is a great showcase of the assets Cisco does bring to bear, including a plethora of delivery models. More importantly, this is just the sort of thing that a CTO or CIO needs when making the case for a NFV build-out budget with lots of zeros in it.

Of course, there is a caveat here.

Those virtualized services Cisco thinks carriers can deliver to SMBs: they are not really new. There is nothing new about managed VPN or security services. What is new here (somewhat) is the SMB target market enabled via a managed services delivery model. Sure, it’s not completely new, but it is a new use case for NFV from the mainline vendors talking up their NFV stories. That’s okay. It is actually better than okay; it suggests all sorts of other “new revenue” opportunities by leveraging virtualization to reach new markets. Take the vEPC use case as one example and those markets could be venue owners, new MVNOs (M2M-focused MVNOS in particular), and every vertical outside telecom. Truly “new” NFV-driven service opportunities may evolve over time. In the near term, however, there should be no shortage of new revenue to be enabled thanks to the virtualization of existing services.

Leave a Reply