There are reasons to do things and there are justifications and any CFO knows the difference. In the last four blogs, I’ve talked about the value propositions for SDN and NFV, how they’re impacted by limited perceptions of the things SDN or NFV have to do, and the kind of holistic model that could define an SDN-and-NFV future. From those, I think we can make some statements on how we’d get to such a future, meaning how near-term value propositions and steps could pave the way for SDN or NFV on a large scale.
Generally speaking, a new technology could be valuable to a network operator for three reasons:
- It reduces capital spending or improves cash flow—what could be called “capex” reasons.
- It reduces operating/operations costs, or “opex”.
- In improves revenue generation by creating new services or creating services more quickly.
Any of these reasons could be justifications for some sort of transformation project, but these projects would in particular likely to be limited in scope. For example, you can justify something like service chaining in business Ethernet access services based on capex. The problem is that the target services don’t account for much more than a fraction of typical operator revenues and costs. If the problem operators face is what they say it is, which is that revenue per bit and cost per bit are going to cross over in 2017ish timeframes, then we need something more massive than diddling down in the single-digit percents-of-revenue-and-costs.
The assessment I’ve made based on fairly extensive carrier dialog can be summarized as follows:
First, there is little chance that operators would gain significant bottom-line value from the capex value proposition alone. “We can get 20% by beating up Huawei on price” is a real comment that shows the challenge of a capex-only solution. No matter what anyone says, capex is not going to justify SDN or NFV deployment at any scale, period. All it could do is provide a service-specific architecture in an age where operators are trying to avoid being service-specific.
Second, operations savings could be very compelling not only as a direct benefit source but as a means of insuring that other benefits aren’t diluted by opex increases associated with a new technology. They could also be obtained at least in part by completely modernizing OSS/BSS even without changing the network, though they could be enhanced with network modernization. The problem is that cost management always runs out of steam as costs approach zero. You need an end-game.
Finally, new revenues created by “service agility” are very difficult to prove out in the near term because they typically require considerable change in both service infrastructure and operations and service lifecycle practices/processes. However, this benefit is likely as durable as changes in the market would be. Service agility demands not only an agile architecture but a framework for finding value and merchandizing it.
To me, the net of this is both interesting and (probably) controversial. In the near term we’d be well served if we could simply orchestrate management and service lifecycle processes; we could avoid making network investment at any significant level and still gain a lot of ground. The question is whether there is anything in place to accomplish that goal. Where NFV comes in is not that you need it for operations efficiency, but that you need operations efficiency for NFV and if you don’t get it in an NFV-harmonious way you may compromise service agility down the line. NFV is a bridge between a current and future model if you extend its MANO concept as you should.
The same is true with SDN. We don’t need SDN to create old services a different way, but to create new services. Those who believe that everything we’re proposing to do with SDN can be done already are right in the service sense. The problem is with our proposals, though, and not with SDN. We are unable to frame the notion of a service in abstract. SDN should have forced us to face that question, as NFV should have forced us to face orchestration of operations. Neither did what they should have.
Everything starts with opex, but operators themselves are divided on just how to achieve operations orchestration. There’s a camp that believes that OSS/BSS simply has to become “event-driven”. Another camp thinks that it has to be completely modernized, and a third camp thinks the whole notion is beyond redemption and should be scrapped. The problem here is that the first group has no specific notion of what event-driven OSS/BSS would look like, the second has no specific track in mind for modernization to follow, and the third has no suggested replacement.
If we accept the 2017 deadline then any major operations overhaul is not in the cards. I believe that effective operations orchestration could be done by applying NFV principles beyond the target scope of NFV as ETSI has set that scope. I think I’ve proved that in two separate projects, in fact. I’m not sure that we could get there any other way at this point, certainly not by 2017. If we’re going to fix NFV in this area, though, it’s vendors who will have to do the heavy lifting. The ETSI ISG and OPNFV alike are still down at the bottom of what has to be a top-down process.
I also believe that SDN needs its own set of benefit-boosters, but unlike NFV it’s hard to say exactly where those boosters are going to come from. IMHO, the best way to promote SDN would be to make it clear how SDN-based services could be created and operationalized in NFV. There is an ETSI ISG activity that’s working on that, but again IMHO it’s hampered by the fact that operations hasn’t been accepted as in-scope by NFV at large. In addition, there’s virtually nothing useful you can do in operations automation if you don’t control legacy infrastructure elements and that was also declared out of scope by ETSI (though it’s working back in).
You have to lead with operations efficiency or neither SDN nor NFV can hope to get off the ground in time to be useful. You could probably get some gains in the service agility area even if you did nothing but totally orchestrate operations, but total orchestration of anything demands IMHO that you have some sort of “intent model” against which you can organize operations processes. The challenge is that at least some operations processes relate to service-and-infrastructure activity that might force you to then move downward and start automating there. That’s why I think the logical approach is to use an NFV-compatible approach to orchestrate infrastructure and network processes, and enhance NFV as needed to make that work.
Presuming we can get to the future with some flair, the challenge is making money there on new services. I believe that there is little or no credibility to incremental service revenue gains from tweaking the characteristics of transport/connection services. Customers who are offered on-demand bandwidth, for example, will exercise the option if their total cost is reduced, which means operator revenues would be reduced. Thus, I believe that all credible new revenue has to come from something other than connection/transport.
Which means, I think, that all credible future revenues are going to come from something that looks at the service-implementation level like cloud computing. New features, new applications, new services will all end up being hosted and the way that all this good stuff manages to be profitable will depend on application of service automation and orchestration techniques to cloud deployment. It will also depend on the availability of features and apps to host, of course, and on service provider marketing that an sell all the stuff. That latter set of requirements can’t be met in the near term, and even the orchestration requirements probably have to evolve out of whatever we do for near-term service orchestration or we’ll be stranding a lot of costs and practices.
This is what poses the challenge for operators. I can make a lot of favorable cost changes in the present with little more than better operations. Over time those changes will have to “descend the stairs” toward infrastructure in order to continue to capture new savings, and eventually we’ll get to the basement. I can do a lot of future revenue growth based on effective cloud infrastructure, but not right away. Logically what we have to do here is to leverage one concept (ops efficiency) in the near term, and another (service agility) in the longer term, then bridge between them.
SDN and NFV, and even the cloud, are facing a crisis of visualization. We have ideas so revolutionary that we’re trivializing them just to make them consumable in the near term. You don’t need revolutionary ideas in the near term, folks. In fact, there wouldn’t be time to develop them. We have an unparalleled opportunity to remake networking and services, and we are going to meet that opportunity one way or another. I think it’s time to decide what the opportunity really is and how we really get there effectively.