Operations costs, opex. Nobody likes it, not enterprises and not operators. Would they spend more on equipment, on modernizing or changing their networks to reduce it? Sure, but with a caveat I’m sure you’ll recognize. Enterprises are happy to spend to reduce opex, if the result creates a reduction that lets them hit their traditional project target rate of return. Is that possible? Here’s the way 42 enterprises who ran all the numbers answered it.
We have to start with how much money is on the table. Let’s say that the enterprise capex budget for a given period is assigned the value 1.00. Our group of enterprises say that on this scale, their netops budget is 0.19, but only roughly half of this (0.09, to be precise) is the hands-off sort of thing that insightful operations software could impact. Would they push a project to eliminate a cost that’s only nine percent of their capex? Sure, but obviously they’d not spend a lot to get to that. Enterprises say that they’d probably not increase their capex by more than 4%, in fact, which isn’t going to warm many vendor hearts, particularly when they’d expect a good chunk of that increase would be taken up by the cost of whatever new tool was needed.
What would give them a bigger pie? The answer is to go beyond basic network opex, which is the typical FCAPS (fault, configuration, accounting, performance, security) stuff. Step up to sustaining user QoE and you have a bigger set of benefits, including the always-popular-if-somewhat-suppositional ones like “better productivity”, “improved sales”, and “customer satisfaction”. So what our group of 42 think is needed is an AI mission that aims at application QoE, and that has to start with what’s come to be known as “full-stack observability”.
When someone finds their application is sluggish or unavailable, there are any number of things that could be wrong. Their own device might have a problem, with hardware or software. The device connectivity might be at fault, meaning its LAN. The application might have a cloud/Internet component that’s twitchy, and the Internet itself might be having one of its days. It could be the corporate network, which means maybe an MPLS VPN, SD-WAN, and the data center network. Or hosting servers, platform software, and the application. It might be several things in combination. Spending to improve the company network part of this doesn’t come even close to addressing the whole QoE picture, so you can’t take the risk of saying it will when you write your project justification. Visibility needs to be complete, and needs to take you down the path to prevention or remediation.
This group of enterprises said that, on the average, the total portion of the budget for QoE assurance that’s made up of human cost would be 0.24 on our scale, which is six times what they say they spend on netops alone. That’s a pie big enough to justify some spending, and that’s the average. The range is from 0.16 to 0.39, so there are some verticals that would have almost ten times as big a pie to address network, observability, and assurance enhancements as netops alone could provide.
Of course, not all that could be expected to fall into the hands of network vendors. All the other possible QoE problem sources have their own associated expenses, since both observability and prevention/remediation measures would be required in each area. However, everyone in the group believed that the network could expect to see a nice piece of the incremental benefit pool, because it’s the glue that binds the whole QoE workflow. It almost surely touches all the problems, and all the solutions.
The critical point that the group makes is that it’s possible to postulate “network probes” that could provide full-stack observability without changing anything else, something no other single element in the QoE-flow can claim. The network would surely have to carry telemetry on full-stack observations regardless of how they were generated. Since every solution to a QoE fault would surely involve harnessing resources, and since those resources could be introduced only through network behaviors, the network is also a part of every solution. One example of this is logging. Even if we assume that our observability probes are scattered through all manner of technology points, getting all this data contextualized demands that it be logged against a common timeline. What, other than the network, can offer that?
This group of enterprises see the role of the network changing; becoming a QoE fabric, an elastic resource that not only ties all the pieces together, but plays the central role in assuring they all play their roles effectively. Who decides a cloud component, or a data center component, has failed? The network, says the group. Who initiates the procedure to restore proper operation? You guessed it.
This doesn’t necessarily mean that the network has to take over all the full-stack observability responsibility, but it does mean that the network has to be involved in it, and in the remediation/prevention roles that come along with the looking-at-and-finding-out piece. Surely, the network has the potential to at least augment any observability measures undertaken by IT and cloud elements, so the benefits that could bring should be considered carefully in any application QoE assurance strategy. There could well be enough there to justify some spending.
Some of our group of enterprises thought that what QoE assurance might do is justify a realistic vision of NaaS. Instead of looking at a network as a static set of connections, look at it as the fabric of workflows, a resource that sees the need to move information, validates it against policies/governance, and then provides it. That includes changing, replacing, augmenting it as needed. This isn’t an essential step in building a QoE-centric vision of network operations, but it would surely be a helpful vision.
Only about 60% of enterprises seem to think that even this radical shift in operations would justify “significant” network spending, but what it would be more likely to justify would be something like a vendor change. In a given year, about 22% of network equipment becomes eligible for displacement, having been fully written down. Could “QoEops” be a justification to switch? Yes, say most enterprises in the group, and that may be important enough to drive vendor action. Visibility/observability is already a big thing with vendors like Cisco, but it could get bigger as vendors come to realize its potential.
