What do operators think makes transformation difficult? That’s a key question not only for operators, but for any who want to drive changes to fundamental network infrastructure principles and architectures. There are technical elements that operators see as barriers, but the biggest ones are far more financial than technical.
I’ve gathered this information from 84 discussions with operators over a period of 11 months. A total of 44 operators were represented, which means that I had about two discussions, on the average, with different people within the operator organizations. All those involved were either CxO-level or senior planners. As is always the case with these contacts, I’ve had longer-term interactions with them, and I promise full protection of identities to all involved, so they can talk freely.
The number-one barrier, one cited in every discussion I had, was residual depreciation on existing infrastructure. Network equipment is written down at different rates in different markets, based on tax laws in each location. On the average, operators report about a five-year depreciation cycle, which means that when they buy gear, they post the cost as an expense over a five-year period. If they displace and dispose of a device before it’s fully depreciated, they have to take a write-down of all the depreciation not yet taken. This write-down will impact the cost, and thus the justification, for any transformation project.
It’s clear that the presence of a lot of undepreciated equipment is a barrier to transformation, but what makes it a special problem is that networks typically evolve, so there are usually a number of devices in place at every possible stage of depreciation. One operator said their equipment was, on the average, three-and-a-half years old, but they had a quarter of it in the final (fifth) year of depreciation and a bit less than that in the first year. If you considered the network as having three layers—access, aggregation/metro, and core—the spread of depreciation across the three was very similar, though access networks were almost always at least slightly “newer”.
The depreciation spread is important because operators were generally of the view that it was “difficult” to displace technology with two years of depreciation remaining, and “almost impossible” to displace something with four or more years remaining. Since none of the access/metro/core network segments were made up primarily of assets with two or fewer years of depreciation remaining, it was difficult to target a transformational change that wouldn’t involve “almost impossible” write-downs.
This raises the question of how transformation could ever be accomplished, of course. One possible answer is the greenfield deployment of mass technology related to a basic change in the network. 5G is the example every operator gives for this kind of driver. When a new service mission comes along, that mission drives greater willingness to displace technology, in no small part because the budget for the mission will include write-down of obsolete assets. But this raises the second-most-cited barrier to transformation, lack of a strong profit incentive to justify new service missions.
Almost half the operators who have deployed 5G already, or who are scheduled to deploy within the next year, say that their deployment plans are hampered by the lack of a clear profit direction on the service decision. All operators who are 5G or 5G-ready say that “competition” is either the primary or second-most-significant driver. The next-highest-rated driver is “enhancement to current mobile network capacity”. Expected new profits on 5G services is ranked third.
This is important because every single operator discussion demonstrated a view that since 5G “mandates” a transformed model of networking, broad adoption of 5G would have the effect of driving transformation through more of the network. It also demonstrates that vendors who offer 5G have a better chance of engaging than those who do not, since there were no other new service missions with any significant credibility at all. This, of course, is already known by vendors, and it’s why there’s such a furor around 5G positioning, not only for traditional network vendors but also for cloud-software and public cloud providers.
We now get to the first “technical” barrier to transformation, one cited by over three-quarters of operators as an “important” issue. Loss of technical and operations continuity without compensatory features to address it, to operators, means that transformed technologies involve changes to network planning and operations practices that aren’t offset by capabilities provided by those technologies. It was a bit surprising to me to hear this point stated this way; I’d expected them to say that “service automation” was a key goal and wasn’t being provided, but operators say service automation is an overall strategy (see below) and not an element of a transformation project.
This issue is most likely to arise in what we could call “point-project” introduction of new/transformed network infrastructure. Router A is at end-of-life, so why not replace it with Transformed-Router B? The problem is that the introduction of a single device within a web of legacy network elements has little chance of presenting any benefits and a significant chance of disrupting operations. Interestingly, operators noted that this is one of the reasons why it’s so hard for a new router competitor to displace the incumbent vendor. Absent a broad service mission change to drive broader change, you’re stuck replacing boxes, and for that, it’s hard to justify a vendor change.
This problem seems almost insurmountable to operators when considering virtual-infrastructure transformation. The problem is that hosted features mean cloud infrastructure, which almost inevitably means major changes in operations and planning. A bit over two-thirds of the operators indicated that they found technical/operations planning and continuity a “major issue” with NFV, and why they believed that the ETSI zero-touch automation initiative really got launched. Without service automation to take up the slack, it’s easy for integration and operations changes to create so much disruption that opex costs override capex reduction benefits.
Most operators don’t believe that we have an effective service lifecycle automation approach; only about a third thought that the ONAP model was workable, a quarter thought some TMF initiatives were the way to go, and the rest really had no useful notion of how to proceed. This was (according to that group) the primary reason why they favored “white-box” networks as a transformation vehicle. With white boxes, the operations could be presumed to be more or less equivalent to traditional operations and integration.
That brings us to what I’ll call the “technical strategy” issues, which really represent the basic approach operators might take to transformation. The first of these, the service mission change has already been talked about. The other two are the opex-driven transformation approach and the white-box transformation approach. We’ll look at these now.
If the service mission change represents a revenue-side justification for transformation, the opex-driven transformation is obviously aiming at operations costs. For the average operator, opex represents almost the same number of cents per revenue dollar as capex does, and when NFV came along, many believed that service lifecycle automation could eliminate the “opex tax” that the additional complexity of chained-virtual-function deployment and the maintenance of the hosting resource pool would necessarily generate. One reason why operators have expressed so much interest in hosting 5G on public cloud resources is their concern over this opex tax.
Opex reduction strategies have other important backers. Current router incumbents like Cisco and Juniper are lining up in favor of an opex-centric transformation because it doesn’t reduce their revenues. In fact, by selling products (like AI enhancements to operations), they hope they might actually increase revenues. The challenge here is that these strategies so far fail the “D4P” (Design for Prevention) test I blogged about last week. It may be that the Juniper acquisition of 128 Technology was aimed at least in part at improving their AI/automation model.
The flip side of opex is capex, and the white-box transformation model is the poster child for capex-driven transformation. About a quarter of the operators in my informal survey have taken a serious look at this, but commitment is still the exception. AT&T is the only major operator who has endorsed, and actually deployed, a large-scale white-box-based network. The majority of that network is deploying on a 5G-related mission, but they also recently announced a transformation of their core to white-box clusters provided by DriveNets.
The operators who are still dipping their toes in white boxes, so to speak, are deterred primarily by the broad question of risk versus cost impact. Estimates of savings attainable via white-box adoption vary from a low of 25% to a high of 50%, and these generally assume minimal increases in opex related to the change. There’s also at least some indication that operators are using white-box networks as a way of squeezing discounts from their incumbent vendors. Even if they’re serious, operators appear to require a fairly significant study period in which to become comfortable with the white-box strategy, and a big part of it is aligning their current business, operations, and network management frameworks to the new model.
This alignment problem is currently the largest barrier to adoption of white-box technology, for two reasons. First, it raises the risk that new operations tools and practices, including service lifecycle automation, will be required to prevent opex costs from overrunning the capex benefits. Most open-model, white-box, solutions don’t as yet have full operations solutions. Second, because current practices are set by router incumbents, it tends to put the white-box providers in direct conflict to the router vendors from the start of the engagement. This changes the point of interaction from the strategic level, where executives who actually have purchase authority live, to the technical level, where router-certified technologists confront the impact of not-router on their own careers.
These two issues have impacted nearly all new operator technology initiatives, and you can see the results in deployment successes. For projects with low-level initiation, meaning modernization and replacement initiatives driven largely by network operations, only 6% of new technology trials advance to production network deployment. For projects with senior-level personnel driving consideration, 63% achieve production deployment.
We can say that, overall, transformation is deterred by risk/reward questions. What contributes to the risk side are concerns about technology change, the need to trust new vendors, the lack of a clear architecture for the new network ecosystem, the need for a high first-cost commitment, and low in-house skill levels with the critical new technologies. Risks are objections at the low level of an organization, and to overcome those “risks/objections”, vendors tend to try to underplay the changes they’re proposing. Every white-box proposal I’ve seen has emphasized the similarity/congruency between white boxes and proprietary routers. The problem with “subtractive” risk management is that the benefits are subject to subtraction too. In fact, these kinds of proposals always end up in a discount war, where it becomes all about price. In the end, the incumbents usually discount enough to win.
And that raises the biggest difficulty of all, a difficulty that operators don’t really mention. Transformation usually doesn’t present enough clear benefits to make a business case. The goal of transformation loses steam in the realization. A big part of that is due to the fact that operators think of transformation as the elimination of a hazy problem of profit-per-bit compression. Hazy problems begat hazy solutions, and you can’t buy those, you can buy only concrete products. When you try to make transformation into a series of project steps, the steps don’t convincingly deliver the operators from that fear of profit compression. Usually because transformation-oriented vendors end up, as I’ve said, focusing on simple cost differences.
Transformation, overall, occurs when you have a transformational technology that can combine with a transformational mission that justifies it. It seems to me that if we assume that there are no credible transformational service missions from which operators could derive significant new revenues, it will be difficult to sustain momentum on transformation, even if it can be started. Cost-driven transformation can only wring out so much from the cost side of profit-per-bit compression. The revenue side must eventually play a role.
That’s why we need to keep working on this problem. Operators have all manner of hopes about new revenue, but for the great majority, there’s absolutely no credible reason to believe in them. One reason I’m so enthusiastic about the network-as-a-service model I mentioned in a blog HERE, is a that an aggressive NaaS positioning could transport some features, value, and revenue from the over-the-network space to the network itself. NaaS is, in a real sense, potential “service middleware”, allowing operators to build components of higher-level service rather than competing with established players in that OTT space. While this may not be the easiest thing to conceptualize or develop, it has the advantage of keeping revenue targets in the service comfort zone of the operators. That may be the critical requirement if anything useful is to be done.