Telstra’s Mark Sanders on open architectures, APIs, intent and NaaS

Five years ago, Telstra embarked on its T22 strategy, a radical change to simplify its business and deliver a transformed experience for customers and employees. Now Telstra is over a year into its T25 strategy. With a focus on growth and innovation its aim is to deliver exceptional customer experiences and to provide future network and technology solutions.

At the heart of T25 is Telstra’s Reference Architecture Model (TRAM), which uses an API-first approach to delivering composable network and technology services that optimize customer experience. Mark Sanders, Chief Architect, Telstra, talked to Inform about the business benefits of using composable network, cloud, IT, and data building blocks.

“TRAM stemmed from how Telstra imagined a modern telco … [with] a growth mindset,” explains Sanders. “We often have good debates internally about the avenues for growth [and] we realized that we needed to work differently and have an architecture that was different to enable it to happen. So, it wouldn’t be about exploring one avenue of growth but enabling several growth ideas.”

A service-based architecture, TRAM spans network, cloud, IT, and data to define all the technology building blocks that Telstra will access through APIs. And its API-first model is endorsed from the top down, says Sanders. “We set very aggressive API-first targets tied to internal, high-level metrics that were steered at the CEO level.

TM Forum’s Open Digital Architecture (ODA) principles are an important foundation of TRAM because they “represent a framework for a modern telco to run its business. It assumes that for a telco to achieve growth, it needs a composable and evolutionary architecture,” states Sanders. “We need a method that doesn't stifle innovation but rather enhances it.”

He adds: “TM Forum and ODA define the principles, domains and most importantly, the Open API interfaces that enable Telstra to build domains with open and re-usable interfaces. It redefines how we integrate and use our suppliers more efficiently and engage in third-party partnerships.”

Network-as-a-service

TRAM has also been informed by Telstra’s industry-leading work on network-as-a service (NaaS), which initiated and shaped TM Forum standards such as the NaaS API Component Suite (TMF909) and NaaS Transformation Guide (IG1224).

“NaaS has been transformative for us,” notes Sanders. Over time the company’s approach to standardizing network services has evolved and its work on network abstraction has led it towards service composition and end-to-end service management.

“Initially, our focus was on a separation of IT and the network,” according to Sanders. “We have now evolved IT, network and data to be offered as a service, so that we can create applications, products and customer experiences … above these service domains.”

ODA helps “reinforce Telstra's commitment to a decoupled architecture,” Sanders says. “This decoupling is pivotal, both at the bounded context level and equally critical in ensuring technology decoupling, allowing us unparalleled flexibility and agility in our operations.”

However, TRAM remains very much a Telstra architecture and therefore incorporates nuances that reflect its strategy. For example, the company has adapted ODA's commitment to customer-centricity to create personalized, on-demand experiences.

Telstra is now building on NaaS by driving its composable architecture further down into the network. It is also “working on how we create NaaS interfaces to enable composite patterns, where multiple customer services have a service relationship to each other,” Sanders explains. “This concept takes many of the guidelines from ETSI and it ensures we can achieve end-to-end service management for our customers.”

Telstra’s efforts to create relevant customer experiences quickly and at scale means “our next evolution of the NaaS will consider how we support intent-based APIs and model third-party services with similar service lifecycle journeys,” Sanders adds.

Increasing autonomy

All of this goes hand-in-hand with developing more autonomous operations that are capable of rapidly and affordably delivering even the most complex future services at scale.

Typically, a telco engineer will redesign and integrate services and create new rules, processes and policies based on their understanding of what can go wrong. Telstra, however, would rather engineers focus on creating the best possible service outcomes for customers and partners.

“We want humans outside the loop, not inside it. This allows labour to be unlocked and focussed on the value,” says Sanders. “In the future we won’t be optimising the network, but instead optimising the model and the outcome.”

Like many telcos, Telstra initially approached automation by creating workflow-driven automation scripts. “Many of these were for activation use cases,” according to Sanders. “Where we did consider assurance-driven automation, they were often added on to the system. The challenge we encountered was that there was still a human commitment.”

Now, the company is “laying a foundation with the principles of domain-driven design and abstraction, where we are considering the bounded contexts of our network and how each has a self-managing management plane,” he says.

Telstra is also applying graph-based thinking to model network topology, which is the same approach China Telecom is taking.

“We are working through how we will develop a knowledge plane to sit alongside the management plane and mix both machine-learned knowledge through AI and human knowledge because we believe that a future intelligent and autonomous network is about information management,” Sanders explains.

At the same time, Telstra is adopting intent-based APIs and natural language interfaces on the NaaS to enable customers to manage network services.

Adapting at scale

Technology underpins Telstra’s transformation. But as with most telcos, the biggest challenge lies in changing culture and processes.

“Architecturally it was relatively simple to get the company on board because everyone throughout the organization can pretty quickly understand the advantages of a Lego-building-block, composable way of working,” says Sanders.

“It was bringing it to life that was exceptionally challenging,” he adds. “We had to change a lot of our skills and our thinking … around how composable building blocks serve a purpose for [several products].”

For example, a move to composable, reusable services and a horizontal business structure “means reviewing planning cycles and investment cycles and review cycles” – and adjusting business processes, all while maintaining operations, according to Sanders.

Telstra has run intensive internal communication programs and provided training, including from TM Forum, to help people adapt to the new way of working. But leadership is essential to success.

“It is about getting momentum up and … a top-down push from our leadership team that this is something we're committed to doing,” Sanders says.

“You do need to plan for it and expect that you will need to rescale and upskill and then put it into your execution plan,” he advises. “Don't try and execute without acknowledging that it's going to be something you need to do.”

“But all in all, we're making great headway, and there's a lot of momentum as we forge ahead. We have taken the work we did in T22 on Network as a Service and the TMF ODA and have evolved that into the Telstra Reference Architecture Model (TRAM), says Sanders.

The reference architecture now extends NaaS, with ITaaS and DaaS (Data as a Service) and is based on the principle of composable architecture.

“At its core, it's about modularity and abstraction championing a service-based architecture and ensuring we’re strategically reusing technology,” says Sanders. “Pair that with our API First initiative and I feel that we're in a much better position to tackle the challenges of T25.”