Is NFV’s Slow Progress a Buyer Problem, or a Seller Problem?

I got up this morning and looked in the mirror and found that I wasn’t Bill Gates.  I checked my bank balance and investments and I wasn’t a billionaire.  There was no shiny new Corvette in my garage.  Here’s the question.  Does this mean that we’ve entered into an era of retail disillusionment, or does it mean that I just didn’t manage my own choices optimally?

The reason behind this opening is that I had an email from an NFV sales type (I get a lot of those).  The argument presented boiled down to the statement that we’d entered into the phase of NFV disillusionment, and the underlying problem was that the buyer insisted on making a business case when they weren’t really “businesses” in the classical sense.

I’ve trashed some sacred cows of next-gen networking and in particular SDN and NFV.  It’s not that I’m trying to ruin the technologies or the people who are trying to support them.  I’m trying to save them from themselves.  Sales, to be successful, cannot consist of convincing the buyer that they’re delusional because they want to know how they’ll financially justify the thing you want them to do.  NFV, or SDN, or the cloud, or anything else out there, is not going to be successful because we trick people into adopting it by exaggerating its benefits and hiding its faults.

For my friend in NFV sales, the truth is that operators are businesses and that they have the same financial demands on them that the NFV salesperson’s own company has.  They have to face the Street every quarter, and they have to make decisions that support the interests of their shareholders, because those are the people a company is directly accountable to, not the customer base or the industry or the economy.  So let’s get off the silliness here and focus on doing what we have to do to prove that network change to NFV or SDN or the cloud is actually a good idea.

If we look at the high level, the business case for NFV is going to be made through insightful application of software-driven automation of service and infrastructure processes.  The notion that operations costs can be reduced without radically reducing human interaction is baseless; that’s where most opex costs are.  So NFV isn’t about virtual functions or process hosting or any of that other stuff; those are just features.  It’s about software automation or it’s not going to get adopted.

Software automation comes in two flavors—lifecycle management of the services and lifecycle management of the service resources.  The reason these two are called out separately is that the former has historically involved managing the financial and contractual relationship between operator and customer, and the latter the management of the technology elements that are committed to fulfill that relationship functionally.  Today, we’d say the service lifecycle management stuff is an OSS/BSS function and the resource management stuff is an NMS function.

The mistake that my NFV sales friend makes, and that most NFV companies make, is that they think in terms of resources only—because they sell them.  NFV, they think, is a revolutionary way of building new services.  We’re in an age of revolutions—the Internet and the iPhone and so forth.  The operators are still in neutral while Apple and Google have the pedal to the metal.  Get with it (and buy my stuff).

Resource management accounts for a fraction of operations costs, about one sixth to be exact, across all carrier classes and in 2016.  The fundamental truth about NFV, or SDN, or anything else we want to propose as a means of transforming operators’ business models, is that there’s not enough on the table to make them transformative if you nail your efforts to the ground in the wasteland of network operations benefits or capital cost reductions.  In fact, I could make a transformation business case at the service lifecycle management level without changing a dollar’s worth of network hardware, more easily than by making changes to the network.

But you can do better by looking at lifecycle management across both services and resources.  You can do better by uniting SDN and NFV into a single technology shift, into a single revolution that is really a cloud revolution.  I said that way back in 2013 when NFV was just getting started, and it’s still true today.  I also sat down with a dozen operators and showed them a model-driven (what we’d call today an “intent-model” approach that did exactly that.  One lifecycle to rule them all.

Why don’t we have this kind of thing happening in NFV sales?  The simple answer is that box people are box people.  It’s not the carriers that are locked in the past, it’s the vendors.  They don’t want revolutions that impact their current sales if they’re network equipment vendors.  They don’t want revolutions that they have to sell to levels of operator management they don’t even call on today.  They don’t want long sales cycles when their management is pressing them relentlessly for success, and where some companies are seriously thinking of getting out of the space.

Why not the OSS/BSS people, then?  Part of the problem there is that there’s nothing more high-inertia in all of networking than OSS/BSS.  Our grandparents would probably recognize the concepts that are in play today.  We’re struggling in OSS/BSS to introduce concepts (like being event-driven) that have been a mainstay of enterprise application design for at least fifteen years.  The political processes inside OSS/BSS standardization (the TMF) make the US Congress look like a band of brothers.  All that’s bad enough, but it’s not the only point.

Our problem with NFV gets back to those bicameral lifecycle targets.  There are two pieces to the network of the future, just like there are of the network of the present.  Services and resources.  The interesting thing about them is that we consider our hoped-for next-generation advance as being a resource evolution even when the benefits we’re going after are predominantly on the services side.  Look at the TMF, who are driving toward next-gen operations under the umbrella of an NFV strategy when NFV needs operations revolutions more than the other way around.

What irks me here, besides the tendency for self-justification, is the fact that we have six vendors out there who actually can do lifecycle orchestration from top to bottom, who can unify the service and resource sides and who can make a business case by drawing on all the cost elements on the table, and add in service agility besides.  These vendors could show buyers right now, today, that an NFV transformation would meet all their goals, and could guide them on the right path.  Yet most of them never even attempt to do that.

And part of this is our fault, “our” meaning the media, consultants, analysts, and yes readers and consumers of industry news.  Are we just junkies for exciting stuff or are we trying to accomplish something here?  If it’s the former, let’s go to the fiction category in Kindle or something.  If it’s the latter, then let’s start pushing back on meaningless drivel about NFV and NFV standards and NFV open-source and ask the real questions about the NFV business case.  That’s what I’m going to do, and if that makes me a contributor to disillusionment in your eyes, I can send you a link to the Kindle fairy tale section.  Happy endings come automatically there.