What does a typical system landscape for fibre operators look like?

As a network operator, you strive towards a business that is well-functioning, profitable and with high customer satisfaction in all processes. It is then more important than you might think with architecture and the system landscape design to keep in mind the integrations between those systems.

Automation and digitization are effective ways to reach these goals. Automation requires that data is available and integrated. Data storage is importance. To store data in the wrong type of system drives costs and creates systems that are hard to maintain.

Integration between systems is important but is a source of short- and long-term costs. Integrations can also be complex and are often uniquely created for every solution. Complex integrations can be a source of problems and make you dependent on expensive and scarce resources.

Few systems can manage everything. But by understanding different systems, it is possible to make good decisions that minimize integrations but still reach the goals of automation.

So, what integrations should be done?

First and foremost, you should automate the processes that often recur and have the most impact on your rollout. Typical examples are “from interest to order,” “order to cash,” and “problem to resolve.” A common denominator for all these processes is that self-service by the customer makes them even more efficient.

Let us investigate a typical system landscape common among Netadmin customers operating a fiber network (as below). In the middle, you have an integrated OSS/BSS, like Netadmin, capable of keeping track of an address and its relations to customers, subscriptions, devices, and different statuses. To the right, you have payment, invoicing, Business Intelligence (BI), and reporting tools. To the left, you have the Sales & Marketing department and their needs in managing the B2B lead process in a CRM, marketing campaign automation, and more manual sales processes like knocking on doors.

If you work with a wholesale business model, you would need to integrate and automate the processes between you and the Service Providers via GUI or API. After the network planning and design are done, the addresses need to be transferred to the operational business support system so that they become aware of the ready-for-sale addresses. At the top, we interact with the subscriber; at the bottom, we communicate with the network.

Here is a description of each of the integration points.

1. The integration to the network is done directly to the network elements or via a vendor-specific Element Management System (EMS). Sometimes there is a RADIUS server for authentication that needs to be configured as well. The RADIUS backend database is modified via CRUD operations. Typical operations are to configure the bandwidth profile and a static IP address associated with the subscriber ID.

2. The integration towards an invoicing system is done differently if the network operator invoice according to anniversary or period billing. Regardless the invoice rows for one-time and period fees are sent to the invoicing system together with customer information. Commonly, there is an integration between the customer portal to the invoicing system to present a PDF copy of the invoice for the customer. In the customer onboarding portal, there might be an integration to a payment provider so that it is possible to retrieve a Direct Debit mandate that is then used at invoicing.

3. The integration between GIS/planning/network design tools to the OSS/BSS is usually done via exchanging a spreadsheet in the start-up phase. An integration between APIs might be needed at very high build-out rates.

4. If you are going to or already working with a wholesale business model, there is often a need for external Retail Service Providers (RSPs) to perform availability checks, place an order and troubleshoot existing customers via some portal. If you have larger RSPs, they might want to integrate with an API. Depending on the market, specific APIs might need to be implemented, e.g., S/PRI in Germany, ON-API in Sweden, and the ALEX platform in Switzerland. Billing is often a semi-manual process when running a wholesale business.

Apart from these four integrations, there might also be a need for integration towards external ticketing systems.

There are some potential pitfalls. One is to introduce an Enterprise Service Bus (ESB) and place a large amount of business logic in such a system. Those systems are for message exchange, not business logic, orchestration, and administration. Another pitfall is starting with a CRM and building everything around that system. CRM systems can be great, but only for certain use cases. The customization and integration costs can be huge when a CRM system grows. CRM systems are not built to manage fixed fiber infrastructure, wholesale, and all the processes around such a business and the address object.

When you design your system landscape, you should investigate the different systems’ strengths and weaknesses. It’s best to avoid too many integrations and develop them according to business cases.

Good luck 😊