SDxCentral raised an interesting point in an article on how Nokia thinks operators would use savings created by virtualization and automation. The point is that operators, having saved on both opex and capex with these strategies, would then spend more on innovation. I believe that the potential for this shift exists, but I also think there are some barriers that would have to fall to realize it. The biggest, perhaps, is facing exactly what NFV really is.
One of the problems with the save-here-to-spend-there approach is that, according to the operators’ own CFOs, the savings that have been proposed for virtualization and automation don’t stand up to close examination. In one of my sweeps of CFO attitude, I found that none had seen a credible demonstration of net savings. Strategies aimed at capex reduction didn’t consider the fact that the alternative infrastructure almost certainly created additional operations expense. Strategies aimed at opex reduction didn’t correctly estimate even the current opex costs, much less what could be saved.
Part of this problem is the effect of the media on claims and research, which I’ve irreverently described as a “Bull**** bidding war.” One vendor says “I can demonstrate a savings of 15%!” The reporter goes to a competitor and says “Charlie over there says he can save 15%, what can you save?” Now this competitor knows darn well that either they beat Charlie’s number, or the story is going to be about Charlie. What do you suppose happens?
The bigger factor, though, is the fact that you cannot even attempt a credible estimate of the cost of a network unless you understand in detail how that network is built. We say “adopt SDN” or “adopt NFV”, but does that mean you to everything with those technologies? We know that SDN and NFV will have a limited impact on fiber or access technology, but how limited? Is the impact in other areas limited too? We can’t know unless we understand just what areas of the network would really be influenced.
On the opex side, I’ve never seen a use case or report that cited how operations costs are actually distributed, or even what they are. One common problem is to take the entire “operations” portion of a carrier and assume it’s network equipment. Hey, guys, they have a bunch of expenses like real estate, vehicles, and do forth that don’t even represent direct network costs. OAM&P costs run to about 64 cents on every revenue dollar, but most of that doesn’t have any connection with network operations and can’t be addressed by automation.
The good news is that while most of the numbers are just smoke, the reality is that there is considerable opportunity to create savings. My own estimates put the achievable goal at about 12% of capex and between a third and a half of opex, and the result of that combination would exceed the total network capex budget of some operators. You could buy a lot of innovation with that.
That raises the second point, though. What exactly does spending on innovation mean? Is innovation even monetizable? If you get a windfall savings of perhaps 15 to 18 cents on every revenue dollar, do you run out into the street and scatter money? You’d invest in something that offered a good return, and “good return” to a CFO means noticeably above the return of legacy infrastructure and services. What that “something” might be isn’t easy to determine.
A massive investment in innovation would mean a massive shift in infrastructure architecture, say from spending on boxes that create connection services to servers and software that create experiences. Historically, operators see this kind of shift as being guided by some standards initiative, aimed at defining the architecture and elements in an open way. Like, one might say, 5G.
5G is a poster-child for the issues of network innovation. Intel calls it “the next catalyst.” We are years along in the effort. We’ve defined all of the architectural goals. We are just now starting to see people talking about the business case for pieces like network slicing. How do you get to this point without knowing what the benefits were going to be? Innovation has to mean more than “doing something different.”
It’s easy to slip from “benefit” to “feature”. There are a lot of things that next-gen infrastructure could do, but it’s far from clear that all of them (or even any of them) offer a high-enough ROI to meet CFO requirements. In the case of 5G, we know that higher customer speeds and cell capacity, FTTN/5G combinations to enhance wireline service delivery, unification of wireline/wireless metro architecture to eliminate separate evolved packet core (EPC), and some aspects of network slicing have at least credible benefits.
Credible, but are they compelling? Most people would agree that an “innovation transformation” would shift much more focus to hosting and data centers. My work on carrier cloud, drawing on the input of about 70 operators, shows that all of 5G would drive only about 12% of potential carrier cloud data center deployment. The biggest factors in carrier cloud deployment are IoT, personalization of advertising and video, and advanced cloud computing services. We should then look to architectures for each of these.
We actually have them. The big OTT players like Amazon, Google, Microsoft, Twitter, and Uber have all framed architectures to deal with the kind of thing all of these true carrier cloud drivers will require. All we need to do is to frame them in the context of carrier cloud, which should actually not be that difficult. The thing that I think has made it challenging is that it’s software-driven. In fact, it would be accurate to say that all “innovation” in the network operator space is really about transformation to a software-driven vision of technology.
Software-centric planning is hard for operators, and you don’t have to look further than SDN, NFV, or 5G to see that. None of these initiatives were done the way software architects would have done them; we fell back on hardware-standards thinking. The problem with the drivers of the carrier cloud is that there’s no real hardware-centricity to fall back on. How do you approach these drivers if you don’t have a software vision?
Traditional NFV plays, including the open-source solutions, have a problem of NFV-centricity in general, and in particular a too-literal adherence to the ETSI ISG’s end-to-end model. Most are incomplete, even for the specific issues of NFV, and can’t drive enough change to really make a business case on their own. There are players now emerging that are doing better, but the problem we have now is that all “orchestration” or “NFV” or “intent modeling” represents is a claim. Like, I might say, “innovation”. Perhaps what we need to do first is catalog the space, look at how software automation of services has evolved and how the solutions have divided themselves. From there, we can see what, and who, is actually doing something constructive. I’ll work on that blog for next week.
