Inventory Migration

The Inventory Population Challenge

Populating network inventories with data is a complex undertaking.

Inventory systems consume data from many sources that were never intended to be integrated into a single body of information. However, this data must nevertheless be combined in order to populate the target inventory system. Meanwhile, the data in the original sources (and in fact, the set of sources itself) continues to evolve during the lifetime of the inventory.

Inventory data migration projects are never as simple as moving data from one source to another – not even when the destination system is simply an upgrade of the existing inventory.

The business can’t stop and wait for the migration project to complete and so the data is a continuously changing landscape of unaligned, overlapping data sources.

Even designing the target model is a challenge, because new data that can’t be accommodated in the initial design can appear at any time during a project, and because extensions and modifications to the information models in network inventory management systems are expensive to make.

Once a target model has been implemented, each load attempt cycle is time consuming and risky, and fallout is difficult to analyse as it only visible through the load errors it causes.

These difficulties, which appear both during the initial migration of data to an inventory and afterwards during day-to-day operation of the inventory system in the form of network reconciliation and collectively represent the most significant risk to the success of network resource inventory programmes.


Ontology for Network Inventory Data Reconciliation

Day-to-day data reconciliation to align the network resource inventory against the actual state of the network is difficult - and many of the tools from inventory vendors do not have the flexibility to manage the rate of change in modern networks.

This creates three main challenges:

1. Minimising maintenance costs of data update “plumbing” between the network and inventory system.
2. Managing fallout that requires data corrections.

e.g. mis-keying in naming conventions, network misconfigurations.

3. Managing fallout that requires model adjustments and identification of those adjustments.

e.g. introduction of new types of configuration or equipment.

Unless all three of these challenges are addressed, the resource inventory will “drift” from the real state of the network – and therefore the business – steadily reducing its value, and, if uncorrected, eventually leading to a derelict state in which business processes which should be fully automated on top of the inventory platform are ad-hoc “patched” with manual steps.

Since the Ontology Dynamic Network Fabric Model is reconstructed dynamically, it represents an up-to-date reflection of the state of the network’s topology, as it is right now – and in the case where Ontology has been used to migrate data to the inventory, it already exists.

Ontology’s low cost of ownership keeps maintenance expense down and its ability to treat both data and model non-conformance without losing visibility means that monitoring the ongoing alignment between the inventory and the network and the network becomes a straightforward part of day-to-day operations.


Ontology for Network Inventory Migrations

Ontology’s Intelligent 360 for Network Operators uses the Ontology 4 Graph-Search Data Alignment and Linking Engine to search through sources of network data to rapidly and cost-effectively construct a Dynamic Network Fabric Model encompassing the network’s topology across all layers, vendors and f technologies.

Since the graph technology in the Ontology 4 platform is schemaless, it can store, manage and analyse data that doesn’t comply with a model, enabling Ontology’s agile data integration approach.

Once this model has been created, the visibility into the data and network that it provides can be used to help design the information model in the target system, ensuring that the design is as comprehensive as possible to begin with. When test-loads are attempted, the fallout can be analysed easily and the results used to drive both required changes into the target model and data fixes into the source systems.

This agile approach to the data integration required to migrate inventory data radically reduces the risk and cost of migration projects, and it also produces a comprehensive topology and model of the network itself – the Dynamic Network Fabric Model.