NFV has a lot of constituencies to appease within each operator to get to deployment, and so far engagement has largely been with the CTO organizations. I’ve noted in past blogs that the operators’ CFOs are concerned about the NFV business case and CIOs are concerned about operations. I thought it might be interesting to review the aspects of NFV technology that are of most concern to the CFOs and CIOs. These might be the directing factors in moving from lab to field trials and deployment because they might be issues that will have to be addressed to get broader buy-in for NFV.
The number one CFO concern is NFVI to VNF/MANO compatibility. The largest investment an operator will make in NFV is the NFVI, and CFOs are concerned that the “best” or “most efficient” NFVI might not be workable with all the NFV implementations. Most say they are not clear on the relationship between the NFVI and the Virtual Infrastructure Manager that’s supposed to link it to the rest of the NFV software. Is there a “standard” VIM, or is there a VIM for each NFVI, depending on the vendor of the hardware and the software? Can you have multiple VIMs, and if not how would you integrate servers from—for example—Cisco and HP?
The number one CIO issue is the viability/scalability of the NFV management and operations model. A service made up of virtual functions could have a dozen VMs, as many or more internal tunnels between them, and linkages to existing infrastructure for customer delivery and transport connectivity between data centers. How this will be managed is completely unclear to the CIOs. The specifications suggest that VNFs present themselves to management systems as “virtual devices” managed as the real devices would be, but that doesn’t address all the management of resources that realize those virtual devices in functional terms. With no clear picture of what could be called “NFVI operations” they can’t validate the opex, and thus can’t sign off on a TCO for NFV.
CFOs’ second-most-significant concern is the VNF cost model itself. The presumption in NFV from the first was that inexpensive software implementations of functionality hosted on commodity servers would be cheaper than actual appliances. What CFOs say is that the providers of today’s devices want to convert them to VNFs and price the licensing such that they have the same profit as before. CFOs are particularly concerned about the “pay as you grow” licensing model, which would increase their fees to VNF providers as customer volume grows, rather than setting a fixed license charge. The as-a-service model seems to CFOs to penalize them for success.
The number two CIO concern is the integration of operations/management processes for legacy infrastructure with VNF lifecycle management. Nobody in the CFO or CIO organizations thinks that future services will be completely VNF-based, and in the early stages it’s likely that most services will have significant legacy device participation. Can you improve service agility or operations efficiency when you’re not able to manage the service from end to end? They don’t think so, and having a different management model for legacy than for NFV makes it hard to even know what management costs would be for a given service—you couldn’t tell what would end up legacy versus VNF.
CFO issue number three is actually also CIO issue number three, but obviously the reasoning is a bit different. The issue is portability of VNFs. CFOs believe that many of the major vendors will develop VNFs that have explicit ties to their own implementation of MANO, VNFM, and NFVI. This makes sense from the vendor perspective; they can use their key VNFs to pull through their implementation of NFV. The problem for the CFO is that they lose pricing power and they risk replication of assets—silos—because they need specific VNFs from different vendors and end up with separate NFV ecosystems because of that.
CIOs’ concern here is in management. They point out that there’s no specific mechanism for federation of NFV assets, nor really any satisfactory model of how multiple NFV implementations could even connect within a given operator. That could silo management visibility, creating a potential disaster for service management efficiency.
Both CFOs and CIOs point out that non-portable VNFs would mean that if a given NFV provider went out of business, failed to keep up with NFV evolution, or simply dropped their NFV product, the operator might have to put together a whole new ecosystem just to continue to sell their current services to their current customers.
The final problem for CFOs is the lack of a convincing point of purchase. What every buyer wants is a collection of credible sellers. Although there are credible sellers for NFV, it’s not clear whether any one of them is sufficient and it’s pretty clear that there’s little basis for combining them to form a multi-vendor ecosystem. Nobody wants a flavor-of-the-month NFV solution, and that seems a real risk now because even the media—ever hungry to name winners in any contest—seems unable to name one with NFV.
For CIOs the final issue is that it’s not clear whether we need an enhancement to current OSS/BSS, a next-gen operations model, or maybe no model at all. Service automation implies lifecycle automation, which could represent a major shift in the way operations software works. The TMF reflected such a shift in their GB942 and NGOSS Contract stuff, but this hasn’t been widely implemented. None of the CIOs I talked with had done so, which is too bad because it might resolve some of the debate on where operations software should be taken. I was at a Tier One operator meeting where two people sitting next to each other had totally incompatible views of what was needed in operations—retaining the old or tossing it in favor of the Great Unknown. That’s reflective of the confusion overall, and that’s a problem because of the obvious key role that OSS/BSS plays in service agility and operations efficiency.
So there we have it. You can see that there are two issues here. First, the “new” players within the operator organizations are yet to be fully convinced that NFV is the right answer (though they really want to believe it is because they’re not sure what else is on the horizon). Second, those new players don’t have the same issues on their bucket lists.
As I’ve said before, there’s no reason why we can’t address these points; even today I think we could meet enough requirements with some of the existing NFV implementations to build the necessary momentum. We do need to meet them, though, and we need to raise all the issues and address them if we want NFV to develop competitively and to its full potential.