Login
Register
Mark Mortensen
The challenges of modernizing network inventory systems
Our new report CSPs take key steps to modernize network inventory maps out the current state and modernization plans of six communications service providers (CSPs) for their network inventory systems. During interviews with those CSPs, I was struck by how we have been struggling with the same set of sticky systems and problems over my forty-five years in the industry.
Most inventory systems have been in place for many years. Why? Because they are deeply embedded in the operational processes and interfaced with many operational support systems (OSS) on one side and with many element/network management systems (EMS/NMS) on the other. Replacing an inventory system is a difficult and time-consuming task, especially since many of them have been customized.
Early in this century I interviewed former CIOs about their old TIRKS – trunk inventory record keeping system – inventory systems, which hailed from the 1960s and were still in place after all those years. I asked when they thought those systems would be retired. One put it best when he said: “Two years after I retire.” The problem was daunting.
Keeping inventory data up to date has and continues to be a major problem. Auto-discoverable network elements were introduced in the last century, although they were not queried often because the processing power of the elements had to be conserved for serving their primary function, not responding to OSS queries. Now processing power is more readily available, but many in-place network elements still are not up to the task of reporting their full set of configuration data.
The second sticky problem is that the network engineering team and the network operations center (NOC) team both need the inventory data, the first for network and service additions and optimization and the second for network and service assurance. The obvious solution is to have a shared view of the network inventory, even the same master inventory system. But these two different organizations have trouble co-ordinating their budgets to implement a unified architecture or a single system (and its evolution). This leads many organizations to have duplicate information in multiple systems for provisioning and assurance, often with differences in the data.
This has always been a problem, but is compounded as automated processes are introduced. Automation does poorly with inconsistent data, both in root cause analysis of issues but especially if closed loop mitigation processes are invoked that span assurance and provisioning processes (and data).
The third problem is that outside and inside plants are managed by different organizations with different systems. In the past these systems had to be separate: the outside plant systems had to be GIS-based to map the physical routes, while the inside plant systems had to efficiently map the complex network connectivity between elements and understand how the services used the resources of the network. These organizations continue to be separate today and will be so for the foreseeable future. To date that has not been a major operational problem, but if network slicing over 5G infrastructure becomes more important, these systems will have to be much better co-ordinated.
But some things have moved on during my time:
Interfaces to inventory systems are standardizing. The TM Forum Open Digital Architecture (ODA) standards include a rich set of interface Open APIs for moving inventory information between systems.
Autodiscovery is becoming ubiquitous. New network elements have a much richer set of capabilities for reporting their configuration to outside systems, especially the new generation of domain control (DC) systems (the evolution of the old EMS/NMS). These DC systems have robust interfaces based on NETCONF/YANG and GTP telemetry, increasingly specified by standards organizations. These standards are now widely required in CSPs’ RFPs.
Better performing network inventory systems are available. New graph technology databases are bringing better performance and open up the possibility of the next generation of inventory systems both inside and outside plant.
Inventory systems are being updated. Vendors of inventory systems are moving their technology base to cloud-native software architecture, built using DevSecOps processes and delivered with continuous improvement and development (CI/CD) methodologies on a hybrid cloud architecture. Every software vendor is making these changes, as the speed and cost benefits are compelling. This will help CSPs with their move to new inventory architectures.
So it’s clear that the industry is finally making some significant progress. Interface standards have greatly improved, the technology for interfacing systems is much better, and the systems are ripe for replacement by new cloud-native systems available from vendors.
I am particularly impressed with the new generation of inventory systems that are being implemented as an overlay above the existing systems, where new systems replace the systems underneath over time. This provides a low-risk, manageable path to system transformation.
