It's been almost exactly three years since a group of global network operators issued the call for action that launched network functions virtualization (NFV), and today it's almost impossible to read any network publication or website and not find mention of the technology. Given that, it seems surprising that more and more operators -- often the very members of that founding group -- are stepping up to say that making the business case for NFV is proving difficult. Why? I've looked at the matter carefully, and can point to three reasons -- two cynical ones and one that's fundamental.
Telling Tall Tales
First, vendors exaggerate mercilessly when they talk about what NFV can do, and the media eagerly accepts nonsense claims. Network operators have cited this specific issue as a problem with NFV justification, because every exaggeration is an invitation to a business case disappointment. The most common problem operators report is a claim of savings (usually 40% or more) without any specifics on the situations under which they might realize such savings.
Operators say they hate this sort of exaggeration because it leads to disappointments when they send an NFV project to the CFO for buy-in. Some CFOs already dismiss most NFV claims as clearly overstated, and others believe them and then wonder why their own companies are settling for less. Either way, it's difficult to overcome the bias that overstated benefit claims make, and impossible to stop vendors from making them.
Steven Spielberg once said that the best advice he ever received as a director was, "When you talk to the press, lie." That's sound advice if a good story is what everyone wants, and you can see how it combines with a natural tendency for vendors to exaggerate claims. A vendor that claims to deliver 40% savings with NFV trumps the one promising 20%, so benefit claims have edged upward.
Strategic Selling
The second barrier to a sound NFV business case is the high sales effort needed to drive the engagement. NFV sales people tell me that they often face a stark choice -- either try to promote some low-ball application of NFV that buyers see as a safe way to start but which won't stand up to CFO scrutiny, or swing for the seats and spend a year trying to build consensus for a broad strategy.
Part of the problem, according to the sales people, is the poor collateral available at the marketing and website level. What marketing doesn't do, sales organizations have to pick up, and those organizations have near-term quotas to make.
Small Thinking
The third and most significant problem with the NFV business case may be a surprise; NFV vendors are thinking too small. It's not that they are shy in claiming benefits, but that they're shy in setting the scope of their solutions. Of all the vendors claiming NFV solutions, less than half a dozen have even attempted to address all the elements needed for the business case. The reason, of course, is that it's a lot of work to do the right thing, and easier in many cases to just sing a pretty song to the media.
Small thinking is most evident in what NFV providers aren't providing. Many have no ability to support legacy infrastructure elements like switches and routers in their management and orchestration products. Most have no ability to orchestrate and integrate current operations support system (OSS), business support system (BSS), and network management system processes and tools -- this when operations savings would have to come from a complete integration of NFV with legacy equipment and with current management software and practices. Even "service agility" benefits demand wholesale operations automation.
A good example is virtual CPE, the replacement of a physical firewall, network address translation, and VPN appliance with a set of chained virtual functions. Some vendors argue that this substitution will save (you guessed it!) 40% because licensing the virtual functions is far cheaper than purchasing the appliance. But what about the hosting cost for each function, the cost of the virtual connections that chain them together, and the cost of operating this complex mesh of elements instead of a single contained device? Well, say vendors, that's OSS/BSS... and out of scope.
Perhaps a more fundamental issue is what one operator calls the "death by ten thousand benefits." Both vendors and the proof-of-concept approach to NFV promote the notion that NFV is not one big opportunity but hundreds or perhaps even thousands of small ones. CFOs trying to run the numbers on an NFV project cringe at the thought of trying to validate thousands of them. Not to mention that the basic notion of an efficient pool of resources and effective service creation and operations practices is hard to square with a driver consisting of a bunch of independent service applications. NFV, to work, has to be a new way of doing services overall and not a better way of doing each service separately.
So why is a NFV business case so hard? Because we don't really want one yet. It's more exciting to speculate about that 40% benefit than to try to deliver something less, even if that something would be enough. It's going to be a hard slog to change that, even with carriers facing revenue/cost-per-bit crossovers in 2017.
Follow Tom Nolle on Google+!
Tom Nolle on Google+
