In a post last week we posed the question on whether Inventory Management still retains relevance. There are certainly uses cases where it remains unquestionably needed. But perhaps others that are no longer required, a relic of old-school processes and data flows.
These use-cases include:
- Passive infrastructure – has no API, so an inventory tool is the only way for systems such as orchestrators to “poll” the network for its latest state / capacity / availability
- Generating Designs – when the design / engineering team plans adds/moves/changes/deletes, especially to physical infrastructure, you might as well keep that information in a form that can be easily referenced by people and systems in the future. An inventory tool is better than storing it in CAD, word processing, spreadsheets, etc
- A Network Graph – in our more complex (read virtualised, self-organising, machine-assigned, etc) networks of the future, assurance use-cases become more challenging, especially cross-domain / root-cause problems. Having a single graph of the network improves our ability to assure and predict / plan the network
If you have an extensive OSP (Outside Plant) network, you have almost no option but to store all this passive infrastructure in an Inventory Management solution (that I’m aware of at least). You don’t have the option of having an EMS (Element Management System) console / API to tell you the current design/location/status of the network.
In the modern world of ubiquitous connection and overlay / virtual networks, Inventory Management might be less essential than it once was. For service qualification, provisioning and perhaps even capacity planning, everything you need to know is available on demand from the EMS/s. The network is a more correct version of the network inventory than external repository (ie Inventory Management) can hope to be, even if you have great success with synchronisation.
But I have a couple of other new-age use-cases to share with you where Inventory Management still retains relevance.
One is for connectivity (okay so this isn’t exactly a new-age use-case, but the scenario I’m about to describe is). If we have a modern overlay / virtual network, anything that stays within a domain is likely to be better served by its EMS equivalent. Especially since connectivity is no longer as simple as physical connections or nearest neighbours with advanced routing protocols. But anything that goes cross-domain and/or off-net needs a mechanism to correlate, coordinate and connect. A holistic network graph is a perfectly suited role the Inventory Manager (LNI and PNI) is able to do (conceptually).
The other, closely aligned with the network graph concept, is for digital twinning. OSS (including Inventory Management) was the “original twin.” It was an offline mimic of the production network. But I cite Inventory Management as having a new-age requirement for the digital twin. I increasingly foresee the need for predictive scenarios to be modelled outside the production network (ie in the twin!). We want to try failure / degradation scenarios. We want to optimise our allocation of capital. We want to simulate and optimise customer experience under different network states and loads. We’re beginning to see the compute power that’s able to drive these scenarios (and more) at scale.
Is it possible to handle these without an Inventory Manager (or equivalent)?Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email