Oracle Widens its Positioning Lead in NFV, but New Issues Loom for All

Of all the suppliers (or even alleged suppliers) of NFV, the one who has shown the greatest and fastest gain in credibility is Oracle.  Over the last year they’ve jumped from almost-nonentity status to one of the three firms most likely to be called a “market leader” and “thought leader” by operators (Alcatel-Lucent and HP are the other two).  What’s behind this, we might wonder.  Well, let’s see.

The main cause of Oracle’s jump seems to be pretty simple.  The company started early this year to promote a very operations-centric vision of NFV.  This was the very moment when operators were starting to realize that the trials and PoCs being run were largely science projects with no direct pathway to proving out benefits needed for a real trial.  Was that a coincidence, we might wonder?  I don’t know of any way to prove it one way or the other.

We also can’t know whether Oracle has been continually developing to their operations-centric NFV vision or whether they’re simply responding to media attention by singing the song that gets the most jukebox nickels thrown.  Oracle’s recent announcements certainly double down on operations as the focus of NFV, and they’re gaining significant traction with operator CIOs (who are the people running the OSS/BSS systems) and with CFOs who think that a new approach to NFV is needed to reap some tangible benefits.

Deep inside, it’s more complicated.  Oracle does have some unique credentials that could be valuable for NFV, but I don’t think they’re particularly tied to operations or OSS/BSS.  If Oracle emerges as a winner in NFV it might well be because they changed horses in mid-positioning.

Efforts to standardize or define NFV have historically focused on the deployment of virtual functions.  That’s not unreasonable given that virtual functions are what NFV brings to the table.  The problem has been that NFV’s prospective benefits—capex reduction, opex efficiency, and service agility—are really difficult to realize if you limit your efforts to deploying those virtual functions.  Services and operations are end-to-end in topology and lifecycle, and so you have to attack them on a broad front to make any difference that matters.

The critical question of benefits has always come down to how you could build a super-efficient form of service automation.  If you could define services so that they could deploy on demand and so that service events could be handled by software, you’d cut the heart out of TCO and increase service agility by orders of magnitude.  NFV correctly framed the notion of management and orchestration or MANO as the heart of the future of networking…but they only defined it for those virtual functions and left the rest of the service and network out.

I said in an early blog on NFV that MANO was something that you could see through three different lenses.  It could be an NFV function and then expand to embrace the total service and infrastructure.  It could be an operations function and expand to embrace NFV deployment.  Finally, it could be something that knows lifecycles and processes and events and lives outside both NFV and OSS/BSS, and unites all the old and new into one model and vision.  The ISG has not taken the first path, and it’s hard to say how that vision could come about without ISG endorsement.  That means the second and third visions are the best shot, and the second is the one Oracle has taken…sort of.

Oracle’s approach to the problem is largely based on what I’ve called the “virtual device model”, which means that NFV is framed to operations systems like a device.  When it’s called for, an independent process resolves the resource commitments needed to make the NFV virtual device into something real.  That approach is a reasonable first step for NFV but it’s not an optimum strategy.  NFV needs to integrate resource and service management, which can’t be done if the deployment of resources and the management of those resources is opaque to operations.

Alcatel-Lucent’s and HP’s NFV strategy are actually better than Oracle’s in terms of implementation, because either would allow for the handling of service events to be mediated by a service model.  Why then is Oracle getting such good traction?  The answer is that while they may not be integrating NFV into operations, they are focusing on modernizing operations overall.

You could gain as much from redoing OSS/BSS implementations around a model-and-event framework as you could gain from either SDN or NFV.  In fact, it’s the operations improvements that are essential.  As operators have moved past the “prove-you-can-deploy-a-VNF” stage of NFC testing, they’ve recognized that to deploy NFV you’ll have to make a business case, not prove a technology.  Central to all NFV business cases is efficient deployment and management.

If you look at the NFV projects that really matter, the ones that are actually trying to prove out NFV’s benefits, you see that they’re divided into two groups, one that approached the issues at the service level from the top down, and the other that approached issues at the technology level.  Oracle’s laser focus on the service lifecycle has given it a lot of curb appeal to the first group, to the point where in at least one Tier One they ended up with a compelling position with the account before any real discussions of NFV features took place.

The question is whether this kind of lead can be sustained.  It’s always dangerous to base your strategy on the presumption that your competitors will continue to give you free rein with a key buyer issue.  However, it’s fair to say that Oracle’s two arch-rivals, Alcatel-Lucent and HP, have so far done just that.

Oracle has a secret weapon, though, in database technology.  NFV operations isn’t a network problem it’s a database problem.  You can’t do NFV management effectively at scale without implementing a kind of database buffer between the resources to be managed and the management and operations elements.  Oracle has all the knowledge and technology needed to do a premier job in that space, though so far they’ve made no comments on it that I’ve been able to find.

And lurking behind all of this are the two pivotal NFV issues, which are intent models and IoT.  The former could finally expose the real issues of operationalizing NFV and so create a scramble for implementations that address those issues.  The latter could be the camel’s nose that pulls a very large vendor under a very important tent, because IoT is a major opportunity for NFV if it’s conceptualized realistically.  Oracle has experience in both these areas too, and so they’re likely to broaden their engagement as time passes.  Since Alcatel-Lucent and HP are likely to start singing operations more effectively to counter Oracle’s early positioning, this will create a three-horse race that could really focus the industry on the right questions for NFV to answer.