Network Inventory Management Problems: The 7 That Strand Capacity, and How to Avoid Them

Why does the project get scoped as storage instead of reconciliation?

The requirement is usually written as a system of record. Somewhere to hold sites, cables, strands, devices, ports and circuits, replacing the spreadsheets and the three inherited databases. That framing is comfortable and it hides the actual difficulty.

The difficulty is that your records already exist. They sit in a geographic information system maintained by outside plant engineering, in controllers and element managers maintained by operations, in as built drawings, and in the head of one engineer who can look at two entries and tell you they are the same facility. What you lack is not somewhere to put them. It is a way to decide which of two conflicting claims is correct, at scale, and to keep deciding.

Scoped as storage, the project becomes a migration, and migrations in this domain either stall in adjudication or complete by having a script pick a winner, which overwrites good records with bad ones at speed.

Scoped as reconciliation, the shape changes. Every entity keeps its source identifiers. Matching rules are explicit, versioned and adjustable rather than buried in a one time script. Conflicts become a work queue with evidence attached, assigned to engineers who can adjudicate them, and the queue drains over months while the system is already useful. That sequencing is why targeted builds get adopted and big bang migrations get abandoned in year two.

What goes wrong when acquired network records are merged?

Three acquisitions means three worldviews, not three networks. One company named sites by street address, one by a location code, one by town plus a number that meant something to whoever assigned it. Circuit identifiers follow three schemes, and one estate numbered strands starting at one per buffer tube while another numbered continuously across the cable.

That last example is the one that causes real operational damage, because strand 37 in one convention is a different physical fiber from strand 37 in the other, and a merged record that normalises them without recording which convention applied will send a crew to the wrong glass. Convention has to be a property of the source record, carried forward and resolved deliberately rather than assumed.

The second failure is splice records. Inherited splice detail is often the least reliable data in the estate and the most confidently stated, because it was correct on the day it was drawn and has since absorbed years of restoration work that nobody documented. Migrating it at equal confidence with recently verified records is how you build a system that is wrong in a new and more authoritative way.

Carry a dated confidence level on everything physical. A splice record verified last month and one inherited from a 2019 acquisition are not equally believable, and pretending otherwise generates the false confidence that makes people stop trusting the system. Route unresolved matches to engineers who can adjudicate them, and record the decision so the same conflict never returns.

Why do discovery and geographic information system integrations break after launch?

Automated discovery is not optional and it is also not sufficient, and confusing those two points is the most common technical mistake in this category.

Polling gives you real logical state: interfaces, configuration, operational status, neighbour relationships, addressing, VLANs and wavelengths. That half is never stale. What it cannot see is dark fiber, patch panel jumpers, splice detail, spare strands or conduit, and it cannot distinguish a port configured for a customer who cancelled from one serving a customer who pays.

The break after launch is normalisation drift. Four vendors have four ideas of what an interface is, and a firmware upgrade changes how a platform reports naming, description fields or operational status. Discovery keeps running and quietly starts classifying things differently. Nothing errors.

On the geographic information system side, the break is usually schema change in Esri or a custodian reorganising layers, after which cable routes import with different attribute names and splice closures lose their linkage. The related trap is coordinate precision: a closure recorded to a rounded position will not associate reliably with the cable it sits on.

Three defences: treat vendor normalisation as versioned mapping with an owner rather than as code, alert when a discovered population shifts in shape rather than only when polling fails, and reconcile continuously so a disagreement becomes a ticket instead of a surprise on a Friday.

What happens when reservations and capacity commitments are not modelled?

Spare capacity as a raw count is nearly useless. What planning and sales need is capacity net of what is already promised: strands reserved for a deal in the pipeline, capacity held for a wholesale customer under contract, ports reserved for a planned build, and everything held back for restoration.

Without that layer you get one of two failures and usually both. Everyone reserves defensively, because an unreserved path can be sold from under them, and you strand your own assets. Or nobody reserves anything and two sales engineers sell the same path in the same week, which produces a missed committed date and a conversation where you tell a customer you were wrong about your own network.

Reservations need to be first class records with an owner, a reason, an expiry and an audit trail. Expiry is the feature nobody asks for and everybody benefits from. A reservation held for an opportunity that closed lost should release itself, and in operators we have worked with a large share of apparently committed capacity turns out to be exactly that. Making it visible is often the fastest return in the build, because released capacity is revenue you can sell without spending capital.

The second modelling gap is restoration holdback. If it is a convention rather than a record, it is invisible to planning, and you will build to relieve a constraint that was policy rather than physics.

Should you build custom or configure what you already own?

If your estate is primarily data centre and metro infrastructure with a manageable vendor mix, use NetBox. It is open source, well designed, actively developed, and for that shape of network it is a genuinely good answer at a small fraction of a custom build. Be clear about what it is: an intent model you populate and maintain, not a discovery and reconciliation engine, and outside plant fiber with splice level detail is not its centre of gravity.

If your data is in reasonable shape and your model is conventional, buy FNT Command or VC4. They are capable telecom inventory systems with proper physical and logical modelling, and they are honest that data migration is a project. Blue Planet, Amdocs and Comarch operate at suite scale on the same premise. A well groomed estate belongs in one of these.

Build when your problem is reconciliation rather than storage. That is the honest dividing line. If you can describe your network cleanly and need somewhere to keep it, buy. If you hold several records that disagree, inherited conventions nobody can normalise generically, and a physical layer whose truth is partly in a technician's head, then what you need is a reconciliation engine wrapped around a model that fits your estate, and that is not something you can license.

Build also when this inventory has to feed fulfillment and assurance systems you are building anyway, because the integration surface between custom systems designed as a pair is dramatically smaller than between licensed products bolted together.

How do hidden costs get into the quote?

A first release covering the unified physical and logical model, automated discovery, source preserving import and a reconciliation work queue runs 90,000 to 190,000 dollars over 14 to 22 weeks in Digital Heroes delivery experience. A full platform adding splice level outside plant with geographic information system integration, capacity and reservation management, circuit design and path computation, and feeds into fulfillment and assurance runs 250,000 to 650,000 dollars over 8 to 18 months. Four things exceed estimate.

Source system count and diversity is the largest. Every legacy record set is its own import, its own quirks and its own adjudication rules, so the fourth inherited estate costs close to what the first did.

Splice level detail is the second and it is the most valuable and most expensive part of the physical model, because the data frequently does not exist and has to be surveyed. That is field cost, not engineering cost, and it belongs in the budget as its own line.

Polling breadth is the third. SNMP, TL1, NETCONF and vendor specific interfaces all behave differently, and the work is not the protocol, it is normalising four vendors' idea of an interface into one model without losing the detail that matters.

The reconciliation backlog is the fourth and it is a people cost. Adjudicating conflicts requires engineers who know the estate, and their time has to be scheduled rather than assumed. Scoping the first release to one region or one acquired estate keeps all four bounded.

What separates a network inventory build that works from one that fails?

Ask a developer to model a path from a customer premises to a node, through a patch panel and two splice closures, then ask what happens when the strand assignment changes at one of those splices during a restoration at three in the morning. If they model connections as a simple link between two devices, they have built a data centre tool and your outside plant will not fit in it.

Ask how they decide which of two conflicting records is correct. The right answer is that the system does not decide. It presents the conflict with evidence and provenance to a person who can, and it remembers the decision. Anyone promising automated data cleansing is offering a script that will overwrite the good record with the bad one at scale.

Ask what they have polled, by vendor and platform, and how they normalise without flattening.

Then be realistic about decay, because it is not a software problem. Records rot because updating them is work performed after the customer is served, by people whose job was to serve the customer. Make the record a byproduct of work: changes made through a workflow the system already runs update it automatically, and field changes take three taps with the circuit identified by scanning a label. Where capture is impossible, run reconciliation that detects drift and raises it.

Settle ownership of the code, repository and hosting in writing before kickoff. At Digital Heroes that is yours from the first commit. And before scoping anything, run one experiment: take fifty spare strands your record claims are available and physically verify ten. Whatever percentage comes back wrong is the size of your problem, and it is the only number in this exercise you should trust completely.