• Swisscom CTO Mark Düsener has outlined plans to simplify legacy kit in the age of AI
• Decoupling services and establishing data foundation are “essential” to unlocking network autonomy
• Düsener was delivering the keynote at Ericsson’s recent OSS/BSS Summit in Zurich

Swisscom CTO Mark Düsener used Ericsson’s recent OSS/BSS Summit in Zurich to explain why simplifying legacy infrastructure, decoupling services and establishing a common data foundation are essential to unlocking autonomous networks and AI-driven innovation.

Swisscom is stripping out legacy complexity in order to accelerate innovation and pave the way for autonomous networks, noted Düsener, arguing that operators must simplify their architecture before they can realise the full potential of AI.

Speaking at the event, Düsener described how the Swiss operator is converging its IP networks, decoupling services through application programming interfaces (APIs) and building a unified data platform to enable faster changes and more autonomous operations.

“Without that, you die in complexity,” he said, explaining the rationale behind why Swisscom began a transformation programme around six years ago. At the time, the operator had 15 disparate IP networks; it is now converging towards a single IP network, with the final stage scheduled for completion in March 2027.

The work also involves decommissioning outdated applications and platforms, although Düsener stressed that modernisation is not an end in itself but a way to create the headroom needed for innovation.

Learning to fail fast

Swisscom’s transformation was triggered, in part, by a series of network outages in Switzerland around five years ago, including one incident that left emergency calls unavailable for nine hours. “Luckily, at night, and luckily, nobody died,” Düsener recalled.

The experience prompted Swisscom to adopt site reliability engineering (SRE), changing how it approaches operational failure and the relationship between reliability and innovation.

“Everything that can fail will fail, and we will make sure that it fails fast and secure,” Düsener said. The approach includes using error budgets to balance reliability against the need to introduce changes. By deploying smaller changes, teams can test updates more easily, reducing their potential impact and allowing teams to experiment and learn faster.

“You have a small increment, you can test it better. You can do more experiments, you can learn faster, and guess what? You have more innovation,” said Düsener.

But this depends on simplifying existing infrastructure first: Swisscom is defining clearer boundaries between operational domains to reduce the number of systems that must adapt when a change is made. According to Düsener, the company had defined 30 different operational domain models (ODMs) as part of this effort.

APIs remove the dependencies

The shift is already changing how Swisscom manages its IP network.

“When I joined Swisscom six years ago and was responsible… for mobile networks, we had 30 IP network engineers in the team,” said Düsener. “They were not accountable for the IP network, but they were working on the IP network.”

Today, network capabilities are exposed through APIs, allowing teams to request changes without manually coordinating every underlying process. “If we need an IP network change or firewall change, it’s an API call,” he said.

The benefits extend beyond the network. Düsener cited the rollout of a new secure access service edge (SASE) offering that was tightly integrated within Swisscom’s network. The project involved around 3,000 engineers, yet the launch date was ultimately determined by the business support systems (BSS) team completing its work.

“The launch date wasn’t determined by anything in networks; it was determined by the BSS being the last one to finish it,” he said.

The problem, he stressed, was not the quality of the engineers but the complexity of the architecture. Swisscom is now reworking its BSS environment, aiming to reduce the time needed to integrate a service from months or years to a week.

AI demands data and context

Düsener argued that true autonomy also depends on providing AI agents with reliable data, the context to interpret it and the ability to act through APIs.

“One is the brain, and that is data,” he said. Without sufficient information and context, agents cannot understand what they are being asked to do.

“If you don’t have data and you don’t have context – explaining what that data is and what that data means – they’re blind and they will hallucinate by default.”

Swisscom currently has some 88,000 APIs across its environment, of which approximately 40,000 are catalogued and roughly 30,000 are up to date. Düsener stressed the importance of having a cohesive API and MCP strategy to ensure AI agents can access the systems and data they need.

The operator is also building a unified data platform to bring together information from process IT, BSS and OSS, using a common Swisscom data model.

Düsener warned against rushing into deploying AI without first completing this foundational work. “If you don’t do the data and context right, [you] will miss the opportunity and take a big risk,” he said.

People remain accountable

Swisscom is already applying AI models to incident triage and operational remediation recommendations, accelerating internal efforts to improve alerts and responses.

But Düsener cautioned that technology alone will not deliver the transformation. Employees must be able to adapt to new ways of working and embrace the change. “I'm a strong believer that psychological safety for people is about being able to change instead of being changed,” he said.

Greater autonomy will shift engineers’ roles to managing and optimising systems rather than executing every change manually. However, even in fully automated workflows, people will remain accountable when things go wrong.

Nor does Düsener expect the transformation to have a defined endpoint. Asked when Swisscom would be finished, his answer was unequivocal: “And the answer is never.”

For Swisscom, autonomous networks are not a project with a fixed deadline, but an ongoing process of simplifying architecture, improving access to data and enabling teams to innovate faster.

“It’s not a project; it’s daily business,” said Düsener.

- James Pearce, Editor, TelecomTV