Telstra accelerates smarter IT and network decisions with ODA

Over the last year Telstra has benefitted from using TM Forum’s Open Digital Architecture (ODA) as a model to support its T25 (and beyond) digital leadership goals.

Telstra’s implementation of ODA is its API-first, Telstra Reference Architecture Model (TRAM). A service-based architecture, TRAM spans network, cloud, IT, and data to define all of Telstra’s technology building blocks. The Australian telco, which was certified by TM Forum as running on ODA nine months ago, has been a pioneer in developing and using Open APIs and ODA to create an ecosystem of digital IT and network services that can be composed, consumed, and reused in multiple permutations.

In the last nine months TRAM’s impact has been widespread, according to Mark Sanders, Chief Architect and Chief Product Architect, Telstra. “Our leadership in architecture is fostering structured and smart technology decisions across Telstra. Our team has laid the groundwork for TRAM which is helping to reduce complexity and duplication.”

Over time Telstra’s deployment of ODA has evolved from initial use by individual teams through to a core part of our business process and governance mechanisms,” explains Sanders. “Now, our architecture is more integrated with our planning, investment, and funding processes and aligned to our strategic direction.”

Evolving the product experience

Designing and deploying an enterprise architecture that structures new ways of working is complex and requires ongoing refinement. One key area where Sanders and his team are applying lessons learnt is in the componentization of a customer’s product experience.

“We've been very structured around how we present [rapid product development] inside of the architecture, and how we form teams -- how we integrate with the right people and ultimately how we deliver a great customer experience.”

In the past, Telstra “literally would model our world: here's the enterprise IT stack, and here's the consumer IT stack.” However, this approach presented challenges particularly for enterprise and how Telstra adapted the product to meet customer’s needs.

In contrast, today a product experience development team can use components to build a product that customers can access via an API or user experience.

“This gives them a lot of agility. They don't always have to go back to the network or IT team to make changes,” says Sanders. “They can keep reusing the components and the APIs and they can keep improving the product and customer experiences.”

It’s also much faster. Telstra has set goals to reduce the product development and release timeframes. In the past “a product owner would have to enter the IT backlog and the work prioritized.” In the composable model, “a product team can execute in parallel to the IT Service Development”.

Product development is also aided by Telstra’s investment in network-as-a-service (NaaS), an area in which it has long been an industry leader. Composite services for multi-service offerings, for example, allow product owners above the NaaS interface to assemble services using ODA components and Open APIs, and combine them with different NaaS offerings, notes Sanders.

Creating outcomes for customers

Telstra now wants to go further with product experience development, by simplifying the task of combining components to seamlessly deliver a range of outcomes for customers.

“We have learnt a lot through our execution and adoption,” says Sanders. “We now need to improve how we assemble components into outcomes [whether] in product development, and the customer experience or a combination of the two.”

In particular, Sanders’ teams have been modelling how to combine a product experience with a customer’s overall channel experience to enhance customers’ use of Telstra’s products.

Sanders points to the example of how Microsoft customers can interact with the company’s products through "My Account", which holds information on all of a customer's devices, licences and support. At the same time, "Office 365" allows customers to configure the product and move between these experiences.

“For example, when they discover they are running low on OneDrive space in the product experience, they can review the purchased licences in the channel experience,” Sanders explains.

Telstra wants to ensure people across the business can “identify components and the maturity of those components and compose them as customer outcomes,” he adds.

Federated architecture

However, as people across the business use components to more rapidly deliver new products and customer experiences, Telstra is changing its approach to IT governance and adopting a federated approach.

“ODA has allowed us to add the common taxonomy, common language, common way of modelling that the entire business can apply to technology design, decision and governance.”

Sanders says his teams are currently halfway through rolling out a federated, consistent approach to technology decisions “anchored in central governance,” called the Federated Architecture Practice.

It will require anyone seeking technology investment “to follow the TRAM”, he explains.

Emphasis is placed on reusability and consistency, whether it’s network components from the NaaS or IT components. In practice, this means anyone developing a new service or feature will have to model components using TRAM and ODA and apply a maturity score and roadmap.

Not only does the Federated Architecture Practice enhance decision clarity and transparency, “it aligns stakeholders, ensuring cohesive architectural choices,” believes Sanders.

Network knowledge

Another important focus is to ensure the company can tap into the knowledge needed to create greater network autonomy.

As Telstra advances in network service design and delivery, and automates more processes, the company is exploring “the development of a knowledge plane to better model how we work in the network,” according to Sanders.

“The concept of data-as-a-service [has] substantially evolved, driven a lot by the emergence of AI,” he explains, adding that at the same time, “an autonomous network has to be dynamic.”

We need to really think of how we build that knowledge plane up,” Sanders says. “We have to figure out how we code the human context of what it means to design that network, and then use that as the foundation for the autonomous network.”