Part of the Ericsson Interviews series featuring insight into the journey to Autonomous Network Operations. What is the key to building autonomous networks? Get the details from Ericsson.

Francis Haysom, Principal Analyst at Appledore Research, talks about the distracting allure of autonomy-level badges and offers CSP executives practical guidance on prioritising and aligning investment in autonomy with business objectives, including what to look for in a transformation partner

Autonomous networks (AN) and autonomous network operations (ANOps) are often talked about interchangeably. Those who make investment decisions at C-level need to understand the distinction. Francis Haysom, Principal Analyst at Appledore Research, has worked for vendors as well as operators in his distinguished career. He explains, “We have autonomous networks already: IP is an autonomous network until you try to change it” – a recurring theme in this interview.

In contrast, “We have highly automated operations for high volume products like SIM cards – there’s a lot of benefit from automating high repeatable processes – but we’ve always had a problem automating operational systems when there is diversity and constant change in what they do, manual processes become the only practical way forward,” he continues.

The greater the need, the harder it gets

As the complexity in autonomy increases “business benefits start to diminish like a reverse exponential curve [see below]. The more autonomy, the shallower the curve and the harder it is to do,” Haysom adds. “And that is before you change things.… changes in the network are autonomy shocks, and so are new products, new orders and new services –  they can easily knock processes back to a lower level of ANOps.”

He notes, “Even with AI, we’re not in a position where the planning or capacity management will be done by anything but a person helped by tools. It’s too diverse to be truly autonomous. On the other hand, dealing with security issues and the volume of alerts coming in, that scale needs automation and autonomy. They are very different investment decisions.”

Haysom has reservations about the over simplistic use of TM Forum’s AN model being seen as the gold standard. “It’s not as simple as that step diagram when you dig down,” he says. “We talk about the ‘chasm’ – there’s a great deal of difference in taking what you do and automating it with technology and having a truly autonomous network. True autonomy can only be achieved through a very big change in behaviour. We term this ‘the network autonomy chasm’.”

Leaning in to autonomy

His thinks autonomy is better seen as a continuous Lean process: “The point is not achieving Level 4 or 5, but to be in a continual state of trying to maintain whatever level is suitable [for a process]. You don’t try to solve every problem; you try to solve the important ones.”

CSPs’ main issue is, “to make autonomous systems much more robust against shocks to operational autonomy: changes in network technology, supply chain, companies merging, etc. Once you achieve that, you’ve crossed the chasm and you’re in a much stronger place, where tools and systems can adapt and recover from constant changes which otherwise can break automations,” Haysom says.

In this light, TM Forum’s AN framework is a good starting place. “Our report, Measuring the autonomy chasm, found a series of measures that build on it, like the scope of autonomy, its goals and how stable it is,” he explains. “Am I trying to deal with 100 future products I’ve never heard of or am I trying to autonomise two that will remain stable for the next decade?

“CSPs need the metrics of a Lean process that constantly strives to understand what’s important and what isn’t, where to invest and where to reallocate resources as circumstances change. A set-in-stone process of step improvement is brittle.”

Measuring ROI can be hard

Not surprisingly, return on investment for automation is difficult to gauge because it must face constant change. “Autonomy goes on forever, it is never done,” Haysom observes. “Therefore there’s a high degree of scepticism at CFO level within an organisation with a history of ‘failed’ transformation projects and the idea that yet one more will solve all the problems.

“You can make and measure some very quick gains, but as we said, it gets harder as things become more complicated. At some point you must decide whether investment in autonomy is delivering higher gains than the cost you’re trying to substitute.”

Seeing the big picture

Yet only measuring quick wins fails to reveal the big picture, firstly in how automation evolves: “We need to know about our automation’s ability to deal with shocks, how quickly and well you recover and when they do, what the new KPIs should look like,” he explains.

For example, in its research, Appledore discovered one operator had been able to reallocate 80% of its NOC [network operation centre] resources by automating a single process. It’s likely that further autonomy gains will be much harder and driven by new business need.

Secondly, ROI isn’t only about efficiencies but new revenues that autonomy supports, like offering products via self-serve, zero touch interfaces, which requires investment: “High value services come in multiple flavours and we need ANOps to deal with assembling many parts. Current automation strategies don’t do this. CSPs must invest to orchestrate things very differently, depending on the service.”

Wasting money on automation?

Does this mean that CSPs sometimes waste money chasing autonomation goals? Haysom says, “We’ve always seen a dichotomy in telco between the specified IT enterprise architectures and operationalising them,” he continues. “CSPs might not address real problem because they are thinking that proofs of concepts, trials or small scale deployments will make the difference but when it comes to operationalising at scale, benefits don’t feed through.”

He continues, “The fundamental question is always what are you trying to achieve? Where are you firefighting? What and where are your highest costs, the most chaos, the highest SLA breaches? Where are problems scaling up, or in danger escalating out of control, like security for example? Anything that is customer driven. Ask ‘Am I competitive in this and should I resist anything that doesn’t have operational buy in?’.”

He insists that operations should be at the centre of software development and cites Swisscom as an exemplar because it treats autonomy, “less as a technical environment and more as an organisational issue.* He says. “It has an overall architecture, but deployed autonomy domain by domain: consequently, the IP, transport and IT people are separate teams but all with operational autonomy.”

Correlation or causation?

It is claimed that CSPs with Levels 3 and 4 AN attain a 19% ROI versus 13% for traditional approaches but are companies succeeding because of autonomy, or despite what they are spending on it?

Haysom says it depends on specific cases but he agrees it could be causation, rather than correlation, based on some observations. First, trawling 10 years’ financial reports of 20 CSPs, Appledore found that capex, opex and ROI levels barely changed.

Hyperscalers have a very different model – “they build and run data centres focused on decline in operational cost,” he explains. Telcos have made a little progress in moving to this model, but minimising opex remains harder to understand and predict than minimising capex, leading to scepticism about autonomy at CFO level.

What do CSPs need in a transformation partner?

Thirdly, experience shows many vendors claim expertise in autonomy but deliver disappointing results. So an important question is what should CSPs look for when choosing a transformation partner? Haysom says, “Managed services are where the rubber hits the road – providers have to make stuff work and can’t be too caught up with esoteric, perfect architectures.

“Operational teams have a huge amount of knowledge and they are both telcos’ biggest allies in and biggest barriers to change – ‘not invented here’ still exists. Working with a partner means collaborate, collaborate, collaborate and recognising that ANOps are not like creating a single project. It means ongoing changes in priorities and automisation must adapt to changing business needs. The ‘end’ vision cannot be fixed.”

Also, the managed service model should be about delivering in weeks and months, not years: “The partner must align with the company and be agile; you’re seeking minimum viable product types to deliver, not the perfect solution all the time,” Haysom states.

Automation brings opportunities

Industry hype aside, what opportunities do ANs and ANOps offer CSPs? He says, “Computing and storage at the edge are already being solved by hyperscalers. CSPs should focus on how their connectivity advantage enables them to be better incorporated into edge solutions, which may or may not come from the CSP, but solves problems for industries beyond telecoms.

Appledore’s research found that about 95% of ‘edge’ use cases can be dealt with by hyperscaler data centres, even to the level of regional data centres within a country. The remaining 5% that do need lower latency are for applications like factory automation and robots. “Then the question is why a telco putting it at the edge is better than an enterprise building its own edge, particularly as a factory will trust its manufacturing systems integrator more than a telco in terms of that solution,” according to Haysom.

He concludes, ‘CSPs’ challenge is to make their connectivity proposition as strong as they can – be easy to integrate with then build out solutions that integrate with the best capabilities from hyperscalers and enterprise vertical experts.”

* See Appledore Research’s case study about the Swisscom Autonomy Blueprint.