Carsten Rasmussen, Head of IT Enablement at TDC Net, the Danish netco, shares his experience of how delayering impacts IT systems. .
What does telco delayering mean for IT systems?
From the perspective of a telco’s IT department, delayering does not result in a clean division of systems, functions and responsibilities. Indeed, it requires the operator to unwind a tangle of existing systems and processes and to reconfigure the direction that any in-progress IT programs will take.
One executive with close experience of delayering gives his view. “You think you have a delayered business, but in reality your IT is still entangled and partially shared, and that is the situation here,” says Carsten Rasmussen, Head of IT Enablement at TDC Net, the netco that resulted from the delayering of TDC Group. There is no simple path to carving up the OSS/BSS environment and handing off functions, processes or data, and then determining which gaps need to be filled to meet new business needs. But it must be done.
A key decision TDC Net had to make in splitting from Nuuday, the servco, was what to do with existing IT systems. There are effectively three options for CSPs considering structural separation, according to Rasmussen:
Divide any system into two or more parts based on the functionality each party needs. This option is potentially the riskiest and most difficult but is often considered because of embedded processes, data and familiarity with a system.
One division holds onto the existing system while the other finds another way – typically moving to a new system or software-as-a-service with a finite amount of time for the migration. This is the most common and least risky approach.
Both sides migrate off the existing system to new ones. In this case, the divisions need to negotiate who is commercially responsible for the end-of-life process for the existing system. This is also a common and fairly low-risk / shared-risk approach.
TDC has used all three options depending on the system. When both sides wanted out of an application, there needed to be a timing discussion. In some cases, applications were split in two. In other cases, each side chose to move to its own, new system.
Ultimately “it can become a race to get out of the legacy systems,” says Rasmussen. Rather than holding onto processes and data, both Nuuday and TDC Net focused on what their new models would require, such as doing business with netcos and servcos other than each other. TDC Net, for example, needed BSS capable of monetizing wholesale connectivity services. Nuuday, on the other hand, decided to replace legacy systems with a new platform-based solution designed to improve customer experience and set the company up as a lean service provider.
In addition to working with TDC Net, Nuuday wants to be able to interact with multiple netcos. The same is also true for TDC Net, which wants to sell services to multiple servcos in a standardized and automated manner. This required the companies to change how they interact with each other.
For example, TDC Net had put wholesale APIs in place prior to the separation to offer connectivity services to thirdparty providers. Now, those APIs will be used to integrate with the new BSS solution Nuuday adopted since delayering. This allows TDC Net to build its new modern technology stack, decoupled from Nuuday.
Rasmussen cites key drivers in completing TDC Net’s structural separation:
Netcos must undergo a major perspective change. “You need to get out of the retail mindset,” says Rasmussen, and this applies to many aspects of the business. “We should be a very simple business, and the main simplification for a netco is on the BSS side,” he says. “We don’t need self-service or an e-shop. We need a very efficient API and super-automated processes for ordering.”
TDC Net has faced challenges finding pared down netco solutions. “On the netco side, you want to put into place a wholesale BSS on top of your stack, but this is one of the challenges because there isn’t really a fit-for-purpose wholesale solution for a netco model yet,” says Rasmussen, adding that there is no need to add the “complexity of a retail invoicing system as a netco.” Indeed, he recommends against it.
The burden of maintaining end customer data should stay with the servco. “We want to drive end customer data out to the extent possible,” says Rasmussen, a recommendation most data privacy and cybersecurity experts would echo. “The only kind of end customer data we should have is the contact details on an order or incident,” he explains. “We need a contact person and a place where the technician needs to go to get access. That is all we need, and it is purely transactional. That’s a tremendous change for the BSS landscape.”
Focus on process automation. Another immediate area of focus for netcos should be “to make processes automated – APIs provide the service providers with a good developer experience too,” says Rasmussen. Other service providers don’t want to be forced to use a TDC Net portal to order services, access data or integrate business processes. They want open APIs and other standards to automate end-to-end processes from the start, with modern systems, tools and pre-built integration.
Netcos must decide where their services start and end. It’s critical to determine “how high in the network stack you will go,” Rasmussen says. As the graphic below demonstrates, a layer 2 business is simpler in that it focuses on moving bits from place to place, while layer 3 gets into more differentiated, secure and quality-assured services. The netco could end up climbing towards the servco part of the stack, which results in more OSS/BSS complexity.
Strategies for growth and new business models will be among the hot topics at DTW24 – Ignite, which runs from 18-20 June in Copenhagen. View the agenda.