The fall is an important time for operators, because they have traditionally embarked on a technical planning cycle starting mid-September and running forward to mid-November. This is the stuff that will then be used to justify their budget proposals for the coming year. We’ve now finished that cycle for the 2016 budget, and I’ve been getting feedback from operators on what they’ve decided with respect to NFV.
The good news for NFV is that over 90% of operators say that they will continue to fund NFV trials in 2016. Very few are saying their current projects will be ending, even to be replaced by other activities. That’s the bad news, though. Only about 15% of the operators said they were confident they would deploy “NFV services” in 2016 and less than half thought they would get to field trials.
The operators who have made the most progress toward NFV have made it by bounding their missions with NFV. Of the operators who said they would be deploying services, well over 90% said their target service was “vCPE”, with about two-thirds of these basing their deployment on premises hosting of agile features rather than in-the-cloud service chaining. Managed service providers (MSPs) who add a management/integration layer to wholesaled transport from others make up about half the vCPE group.
The reason this is important is reflected in the next point. Only about a fifth of the operators who say they plan deployments in 2016 say they have plans to extend their initial NFV commitment to other service areas—even beyond 2016. Further, while nearly all this deploying-services group describe what they are doing as “NFV”, fewer than 1 in 10 base their deployment plans on a real, full, NFV implementation.
A Tier One who offers managed services offered the best description of what’s happening. NFV, says the CFO of this operator, is attractive as a framework for delivering portal-driven agile feature delivery to customers. They see managed services as an opportunity to climb the value chain, but their vision of implementation is really more about a service catalog and portal linked to a simple CPE management system that can load features than about full NFV.
This operator does have further NFV plans, though. They are looking at services in IoT and mobile content for the future, and they see something more like “real” NFV as a pathway to deploy services in both areas almost on a trial basis. “It’s the fast-fail model,” the CFO says. “We deploy generalized infrastructure and we use that to test service concepts the only way that really works…by trying them in the market.” This is what that particular operator needs service agility for.
There is a question of whether even this is “real NFV” though, and even in my reference operator. The CFO admits that the operations organization and CIO have only been recently engaged in the activity, and that they are still unsure as to how they’d operationalize an NFV infrastructure and its services. Their early target services are those where either there is no specific SLA experience in the market to conform to, or where SLAs are largely met by managing the infrastructure (NFV and legacy) as a pool of resources. “NFV management for us is data center management plus network management,” my CIO friend admits. “We don’t have a strategy yet that can unify them.”
All of this seems to point to an NFV evolution that’s far from the traditional way services and infrastructure have evolved in the past. We have not been able to make a broad business case for NFV yet, though at least half-a-dozen vendors could in my view deliver the necessary elements. Given that, what has happened is that operators have effectively extended the early trials and PoCs that aim toward a specific service-of-opportunity, hoping to prove something useful out along the way. But doesn’t this present that old bugaboo of the silo risk? It sort of does, and here we have some interesting commentary.
“NFV silos don’t worry us as much as silos of legacy gear,” the CFO admits. “NFV’s primary cost is the new data centers—the servers. The secondary cost is operations integration. We don’t have the primary cost at risk at all with NFV because the infrastructure isn’t service-specific. We don’t have ops integration yet so that’s not a potential sunk cost. So we have a risk-less silo.”
That’s not a long-term strategy, as well over 80% of operators with specific NFV plans for 2016 will admit. They believe they will be evolving toward that utopian true NFV goal. The problem, they say, is that they can’t reach it yet.
What? Do operators think nobody can deliver on NFV as a whole? That’s pretty much what CFOs and CIOs think, for sure. When I tell operators that six specific vendors would be able to make such a business case, they smile at me and say “Tom, it’s great that you can tell us that and even name the vendors, but you have to understand that we can’t deploy based on your assurances. The vendors have to make the claim and back it up, and they are not doing that.”
That was the key result of my discussions, I think. Operators are saying that it doesn’t matter if you have a complete NFV strategy because you probably can’t or won’t sell it to the operators. Everyone has gotten so focused on islands of NFV that the whole NFV process has evolved to letting clumps of stuff driven by the wind and currents aggregate into little islands that will in time eventually make up a significant land mass.
In a vendor sense, who then does the aggregating, the building of that full NFV? Not the early vendors, and in fact probably not even vendors who have NFV solutions. Operators are seeing this increasingly as an operations step taken after early per-service trials. Because CIOs haven’t been fully engaged so far, we have operation-less NFV, and the CIOs want to add operations by adding OSS/BSS tools above whatever NFV stuff lives below in the service layer.
If all this holds in 2016 it could have profound impact on vendors. Smaller players might hope to drive service-specific NFV solutions that could in time be collected at the OSS/BSS level. Larger vendors, though, will have to present something much more OSS/BSS-intensive as their central element because only that story would appeal to the CIOs who will likely drive the next step—the step beyond 2017 when NFV silos are collected.
I don’t think this is the optimum way to do things. I think it will string NFV deployment out for five years when it could have been done in three. I also think that we’ll sacrifice a lot of efficiency and agility by failing to fully integrate infrastructure orchestration and management with operations orchestration. I’d have bet the outcome would have been different, but I’d also have bet that the vendors who can do full NFV right now would have pushed their capabilities more aggressively. Now, according to operators, the opportunity to have a MANO-driven merger of infrastructure and operations has passed.
This isn’t going to stop NFV. The risk that operators would drop it and look for solutions elsewhere doesn’t appear to be significant according to my discussions with operators themselves. But it will change it, and how those changes will work through NFV functions and standards, and how it will impact vendor and market dynamics, will be one of my blog focuses for the coming year.