Over the last year I have been trying to understand how network operators make a business case for a migration to SDN and NFV. It’s easy to see how you can build them into a few services or projects here and there, but we seem to be lacking the impetus to drive a wholesale shift in infrastructure. Server and chip vendors, in particular, need to try to exploit the potential hundreds of thousands of incremental servers that such a shift could justify. The problem is that it’s not clear how all the pieces come together.
I’ve gathered good cost data from operators as well as constraints on a shift in technology, and pushed them through my model of the market. The result is an interesting view of network evolution, one I intend to share here.
From a benefit-driver perspective, network evolution has two paths forward. One says that you make the equipment needed to support services cheaper—this is the “capex reduction” benefit. The other says that you make network operations processes more efficient and agile—the “opex and agility” benefit. The two can be symbiotic, but there’s a basic tension between them as well.
If we presumed that networking were to be remade by deployment of SDN and NFV in some mix, then the pace of evolution is constrained by the pace at which SDN/NFV changes could be introduced into the network. One barrier to this is the financial inertia of current infrastructure, and another is the need to establish a suitable operations framework that could at least guarantee no loss in efficiency during the SDN/NFV transition. Even if we solved this second problem (which neither the ONF nor the ETSI ISG has put into their scope), the first of these problems would limit the rate of SDN/NFV introduction, particularly in the next three years.
If, on the other hand, we presume that remaking networking was going to happen by remaking services to optimize the use of service automation to improve efficiency and agility, we would have no sunk-cost barriers to deployment of our solution but also have no direct capex reduction. An operations-centric service-automation approach can happen above the current network, though, and also above any future infrastructure technology changes. In that position it could facilitate the introduction of new equipment and technologies like SDN and NFV.
Operators have told me consistently that they do not believe that capex reductions for SDN or NFV are compelling reasons to shift to these new technologies. They are particularly concerned that the more complex service topology created by function-hosting and service chaining will add more operations costs than it reduces capex. Operators are also concerned about new-revenue service agility benefits, which they believe vendors have been over-hyping. It’s easy to say that users would buy X or Y or Z if you presented them in a certain way, but until that presentation is made and you can test the theory, it’s only a guess. Thus, for this discussion, we’ll focus on opex.
The opex category of operator costs includes customer acquisition/retention, network operations, customer technical support, IT operations, metro backhaul charges paid, and energy costs. The first four of these are what I call “process opex” meaning that they directly relate to human operations costs and thus can be directly impacted by service automation. These costs make up about 88% of opex and in 2016 will account in total for about 23 cents of every revenue dollar for operators. Capex accounts for only about 19-20 cents. Operators also say that these costs will grow to 28 cents per revenue dollar in 2020, which contrasts to expected growth of less than 2% annually in capex. Some costs, like customer technical support, are expected to increase by 22% by 2020, a daunting prospect for operators.
My model shows that by 2022 either a service-operations-driven or SDN/NFV-driven modernization can reasonably be expected to reduce total opex by about a third, which is about 7.5 cents per revenue dollar. How the two approaches get to that savings is very different, however.
With SDN/NFV, the challenge is timing. Because the pace of infrastructure change needed to adopt SDN and NFV is so limited by the depreciation of current assets, the SDN/NFV path secures less than a third of its total 2022 savings even in 2018, and this presumes aggressive adoption without any limitations created by perceived risk or operations cost questions. If we presume the current pace of risk management for SDN/NFV, the adoption rate is only about 40% of this optimum rate, and even in 2022 we’d see less than two-thirds of the target 7.5 cents per revenue dollar benefit.
Service automation shows a totally different picture. Early savings growth is very rapid because there are no significant financial inertia factors to deal with. On this path to opex reduction, savings grow so fast that they achieve the SDN/NFV savings rates two years earlier. By 2020 the service automation path has saved operators twice the opex of the SDN/NFV path. There’s also the issue of ROI. As I pointed out in my blog yesterday, achieving opex reduction through SDN/NFV modernization costs about five times as much for the same level of savings.
It’s not all beer and roses for service automation, though. A pure service-automation transformation hits the wall in about 2023 because of limits in how agile and efficient current network technologies can be. SDN/NFV transformation continues beyond that point, and by about 2025 has cut opex in half and by 2027 SDN/NFV has made up the cumulative savings deficit it had relative to service automation.
This, I think, makes it clear that the best solution is to combine these two initiatives. If we had the service automation benefits created in such a way that they worked now with legacy infrastructure and facilitated SDN/NFV evolution (what I’ve called the “operations-first” approach), we could actually fund SDN/NFV transition with early service automation savings and achieve the 2025 optimum savings targets as much as three years sooner. More and more operators are turning to this approach, though they don’t publically link their plans to the kind of savings progression I’ve cited here. Verizon made a presentation that specifically detailed plans to first abstract current network features and then evolve them. That’s the right answer.
Of course, you also have to abstract in such a way as to facilitate realizing the service automation goal. It would seem that the ideal situation would be to convert current OSS/BSS/NMS processes into microservices that could then be integrated with service lifecycle management states as a service deployed and moved through various sets of issues. The one risk that I see in focusing on abstracting legacy technology is missing the need for these microservices. After all, we already have management orchestration in classic networks—the international model of EMS-NMS-SMS progression implies layers of increasing service awareness. It would be all too easy to simply rename stuff that’s already out there, declare it a service automation solution, and forget that we’ve not moved the ball.
This risk is most likely a factor for big network vendors and for OSS/BSS vendors—the former because they really don’t want much evolution in infrastructure and the latter because they don’t want to do too much new stuff. That’s why having an operationalizing software model and orchestration within SDN/NFV would have been so helpful. We still may get it, but it’s getting harder every day.
That’s the real lesson of these numbers. We could do the best thing possible by uniting the software automation and SDN/NFV movements, but if the latter stubbornly refuses to address an opex-dominated end game, then harmonization will be very difficult. Salespeople tell me that 1) it’s very hard to do a unified sell of SDN/NFV justified by a broad capex/opex business case and 2) their own companies don’t want them to do that because they won’t make near-term sales goals. Well, those goals are at risk now in any event, and is the long-term SDN/NFV future if software automation gets out in front.
