How to shift to intent-driven automation

The idea of intent-based networking has been kicking around the telecoms industry since at least 2017. However, serious industry conversations of intent as a driver of telecoms operations automation are only now progressing, as our recent report on intent in autonomous networks explores.

Interest in intent is growing because the increasing complexity of business, service and network operations is making it difficult to manage, control and assure customer experience, service operations, cost and network performance using today’s tools and approaches.

There are many steps in the shift to intent-driven automation. In this extract from the report we consider what communications service providers need to do, including:

• Grapple with significant inherent complexity, such as how to incorporate resources and interfaces that are outside the intent-based components of the system. The best way to encapsulate domains and subsystems and their existing non-intent-based APIs and approaches is to leave them untouched (and unbroken). Intent-based APIs can be implemented at the integration/ demarcation points between autonomous domains while leaving the non-intent-based systems within those domains to execute appropriately. This approach is analogous to the way that vendor-agnostic cross domain network orchestrators work with vendor-specific domain controllers to create end-to-end services: the network orchestrator does not need to worry about the details of the vendor-specific implementation, it just needs to communicate with the vendor network or functional element through an open, non-proprietary API, which could be non-intent-based.
• Think through the implications of the TM Forum Autonomous Network Project’s proposal on intent-driven operation, including the impact of intent-driven approaches on regulatory, legal, security and governance imperatives to which they may be subject.
• Learn to trust increasingly more automated operations on the way to autonomous operations. Delegating responsibility, especially to machines, makes many people uncomfortable. Only through seeing the system suggest the right actions time after time will telecoms personnel grow comfortable enough to eliminate go/no go manual decision points. One CSP acknowledged that although his company has a strategy to implement AN, its network engineers are understandably risk averse and protective. The notion of going “all in” is too much, so the company is focusing on sets of automation changes and working to close the loop where they have high certainty as to how to fix problems that do arise and where the repercussions of a failure to fix a problem are minor.
• Shift mindsets. Beyond simply learning how to trust autonomous systems, there are more fundamental issues regarding whether organizations are ready to leap into the unknown. One vendor interviewed for this report noted, for example, that it helped a CSP implement automated operations capabilities that learned as they went along, and which could automatically address 95% of the CSP’s network issues. The CSP’s network operations teams, however, would not allow the system into production because they felt they could neither understand nor control it. Embracing change will take top-down support and encouragement, education, training and the creation of opportunities for ownership of the change.
• Grow expertise. Knowledge graphs, ontologies and other fundamental concepts of making intent-driven operation a reality have been embraced by hyperscalers for some years; these concepts are a fundamental part of Kubernetes-based cloud computing and autonomous system operation in data centers. Because these concepts are new to CSPs, personnel will need to learn to use new modeling and interface development approaches, such as the RDF-based software stack mentioned in section 2, that are built for dynamic, knowledge-based systems. One CSP noted that it has been building its internal expertise, for example, on software-defined networking over the past several years; the service enhancement opportunity this approach has brought is now clear. Even so, he says: “In the network itself we are relatively risk-averse, so we are building up our internal capabilities incrementally, cautiously and in an agile manner.”
• Ensure they have the right data available when and where it’s needed. Aaron Boasman-Patel, TM Forum’s Vice President, AI & Customer Experience, and the AN project lead, notes that “data is the oxygen required to implement intent properly.” Few CSPs today can confidently say they have a data strategy in place that will let them easily unlock the door to intent-driven operations.
• Engage more frequently with enterprise executives, not just network engineers, during the sales process. One CSP noted that rather than engage with a customer’s network engineers, it would be better to engage with its executives; only then could they fully understand the customer’s business intent rather than just their lower-level intents. When a customer wants to set up new office or retail locations, for example, the CSP and its systems need to understand the essence of what they are trying to do, not just have them pick from a service catalog.
• Consider how to implement greater customer self-diagnosis of service issues. It would truly be a bonus for CSPs and their customers if intent-driven automation could also expand customers’ ability to self diagnose and automate repair of service problems.

Read our report Intent in Autonomous Networks to find out more.