How CityFibre is using Open APIs to dynamically serve ISPs

CityFibre is combining its rapid UK fibre network rollout with an API-first approach to dynamic network service provision for its Internet Service Provider (ISP) customers. Florin Tene, Enterprise Architect, CityFibre, shared with Inform the advantages of exposing Open APIs to these customers, its work on events-driven architecture and why it is adopting TM Forum’s Open Digital Architecture (ODA).

With one of the UK’s largest full-fiber platforms, CityFibre has already passed over 2.5 million UK premises with its fiber network. Once complete, its rollout will reach 8 million homes, 800,000 businesses 250,000 mobile sites and 400,000 public sector sites nationwide. As it grows, CityFibre wants to make it simple for ISPs to automatically consume services, while increasing its own flexibility and ability to work easily with different suppliers and partners. For this reason, it is drawing on TM Forum’s Open APIs and Open Digital Architecture (ODA) to build a cloud-native architecture.

Tene, who joined CityFibre from Vodafone, is helping CityFibre adopt TM Forum standards, which includes mapping the TM Forum frameworks and identifying which API to deploy in each layer. “It’s an API-first approach. We treat each API as a product and we're clear on which domain should expose which API. We’ve been through the whole transformation journey, including Open Digital Architecture [ODA] mappings internally,” explains Tene.

CityFibre’s service delivery model depends on cloud scalability and the orchestration of numerous elements, which is why using the standard TM Forum APIs for all interactions within the architectural landscape was mandated. “Because we have decoupled layers, the Party and Core Commerce domains will say I want this service delivered to this customer and then it's up to the Production/Service domain to say ‘I have the requests for the service for this customer. Which resources do I need to provide it?’ And then one layer down, the Production/Resource domain will act.”

“If you think about this in ODA terms, each one becomes an ODA component and you standardize this interaction between the ODA component models. For example, service order management is one component, the resource order management is another component, and then each co-operates,” explains Tene.

With its new Operational Support Systems (OSS), CityFibre wants to ensure the rest of the business can "merge, combine and bundle services and products as they want without us even touching that stack," says Tene. “In addition, we want to be able to add new hardware manufacturers without code change in order to reduce our costs. Most importantly we want to enable new capabilities to our partners,” explains Tene.

CityFibre also needed a system that could enable smart orchestration on its network, manage thousands of network assets at scale, and provide the right amount of information to its service assurance stack.

“The challenge was to find a smart OSS that can do this kind of orchestration. It needed to align to the TM Forum and our vision, allow us to decouple between layers, and manage our inventory,” says Tene. “We identified what the gaps were and worked towards our architecture harnessing the benefits of the ODA components, being based on decoupled domains, with abstraction between domains. For example, from the Core Commerce domain, the commercial order is decomposed into the service domain and everything that proceeds is a service order which is further decomposed into the underlying layers,” he explains.

Event-driven

Another imperative was to standardize CityFibre’s event-driven architecture (EDA) – a key aspect of its existing service delivery. Typically used in association with applications built based on microservices architecture, EDA enables decoupled services to communicate, and helps CityFibre process high volumes of complex requests in real-time, without needing point-to-point integration.

“An EDA supports loose coupling between components, greater agility and allows for significantly higher volumes of data processing and significantly higher speeds. This is because you don't have to wait for other systems to respond,” says Tene. Crucially, an EDA fits with CityFibre’s wider strategy of automating service delivery while being highly responsive to its ISP customers’ needs.

CityFibre’s use of EDA was not covered by TM Forum’s Open APIs though, which were based on the REST standard for synchronous architectures. Tene therefore collaborated in a TM Forum Catalyst, called Async Open APIs for event-based architectures, alongside peers from BT, Jio, Orange, Telenor, Verizon, Vodafone, Aria, Bit2win, EPAM, Tech Mahindra and Yupiik. Together they worked on ensuring that the underlying definitions, design patterns and schemes of TM Forum’s Open APIs are reused for event-based interoperability.

“CityFibre, drew on its agility and rapid pace of development to create AsyncAPI specifications, that aligned with the existing TM Forum ones,” explains Tene. As a result, “we have a foundation of event-driven architecture domains, and we have some additional REST APIs going to our partners,” says Tene, adding: “And of course, the more APIs we adopt and expose to our partners, the more services you can provide to ISPs and the lower the cost of integration.”

This is not Tene’s first experience of digital transformation, but changes within the industry, including the development and adoption of TM Forum’s Open APIs and ODA, mean he believes it is far easier today than it was – even a few years ago.

“TM Forum has done a fantastic job of bringing everybody to the table to enable this integration, which – just six years ago – would’ve been extremely challenging to achieve,” says Tene. “Today, we have APIs and decoupling, thinking in the cloud and ODA components. This is where I believe we’ve seen the material difference this time.”