The Hidden Cost of Undocumented Network Knowledge

Most network teams don’t say:

“We have an undocumented network knowledge problem.”

They say:

“Ask the person who installed it.”
“It should be in the old Visio diagram.”
“There’s a spreadsheet somewhere.”
“Someone on the fiber team knows.”

This “system” may work for a while—until that person is unavailable, retires, or leaves the organization.

Then the team discovers that critical network knowledge wasn’t stored in a dependable system of record. It was actually living in people’s heads, outdated diagrams, and disconnected files.

That’s not just a documentation headache.

It’s an operational dependency.

What Is Undocumented Network Knowledge?

Undocumented network knowledge is information your team needs but can’t reliably find in one shared system.

It could include:

• How two buildings are connected
• Which fiber strands support a circuit
• Where a cable is physically routed
• Which ports and devices are connected
• Which services depend on a particular path
• What changed during the last upgrade
• Whether the documented route still matches reality

The information probably exists somewhere…

Some of it is in an employee’s memory. Some is in Visio or Excel. The rest may be scattered across emails, ticketing systems, paper records, monitoring platforms, and files named something like:

Network-Final-Updated-V7-Really-Final.vsdx

That’s not a system of record.

It’s a scavenger hunt.

Shared documentation is better than information living only in people’s heads. But a folder of diagrams and spreadsheets still isn’t necessarily a system of record.

A system of record connects infrastructure data, physical relationships, routes, circuits, capacity, and changes in a form the organization can maintain and use operationally.

netTerrain organizes infrastructure in a connected diagram hierarchy, helping teams navigate from higher-level locations and diagrams to the equipment and relationships beneath them.

Memory Is Useful but It’s Not an Infrastructure Platform.

Experienced employees remember why a cable was rerouted, which circuit received a temporary patch, and why a seemingly available strand shouldn’t be touched.

That experience is invaluable.

The problem begins when it’s the only place the information exists.

Human memory isn’t searchable by the rest of the team. It can’t produce a capacity report or preserve a reliable change history. Most importantly, it doesn’t scale as the number of sites, devices, circuits, fiber routes, contractors, and employees grows.

Eventually, “ask someone” stops being a process.

Where the Cost Actually Appears

Undocumented network knowledge rarely shows up as a clear budget item.

You don’t receive an invoice labeled:

Cost of not knowing where anything goes: $147,000

Instead, the cost hides inside onboarding, outages, delayed projects, repeat site visits, unnecessary purchases, and time spent reconstructing information the organization once knew.

Onboarding Becomes Reverse Engineering

A new network engineer needs more than device names and IP addresses.

Depending on the environment, that person may need to understand:

• Physical and logical topology
• Devices, cards, ports, and connections
• Building-to-building connectivity
• Fiber routes and pathways
• Splices and patching
• Circuit dependencies
• Available capacity

Without accurate documentation, onboarding becomes an archaeological dig.

The new employee studies old diagrams, compares conflicting spreadsheets, corners and interviews experienced team members, opens cabinets, traces cables, and tries to determine which records can still be trusted.

Meanwhile, the people with the most knowledge spend their time explaining the same infrastructure again and again.

This is especially painful for universities, municipalities, utilities, transportation systems, airports, and other organizations managing geographically distributed infrastructure.

A network spread across a campus, airport, or city is difficult enough to learn.

It shouldn’t also require detective work.

Outages Begin With Investigation Instead of Resolution

During an outage, the team needs answers quickly:

• Which locations are affected?
• Which circuit follows the failed route?
• Which cables and strands support it?
• Which devices, ports, and services depend on the connection?
• Is there a physically diverse alternate path?

When those answers live in people’s heads or disconnected files, troubleshooting begins with information gathering.

Someone calls three employees.

Someone else opens two versions of a diagram.

A technician is sent to inspect a patch panel.

Another person tries to reconstruct the path from ticket history.

None of this repairs the failure.

It only establishes what the infrastructure is supposed to look like.

The technical problem may be straightforward. The delay comes from not understanding the relationships around it.

A netTerrain block Circuit Layout Record provides a visual view of an end-to-end circuit path, including the nodes, ports, and connections involved.

Capacity Planning Becomes Guesswork

Fiber capacity isn’t useful when nobody trusts the records.

Teams need dependable answers to questions such as:

• Which strands are available?
• Which strands are assigned?
• Which ducts or tubes have space?
• Where can a new circuit be routed?
• Which route provides real physical diversity?
• Does the documented capacity match what’s deployed?

Without those answers, organizations tend to do one of three things:

1. Delay the project while someone verifies the infrastructure.
2. Purchase capacity they may already own.
3. Install the new service and hope the records are close enough.

“Close enough” isn’t a great capacity-planning method.

Audits and Change Reviews Become Harder Than Necessary

Organizations may be asked to produce records of topology, inventory, connectivity, infrastructure changes, and service dependencies.

Documentation software can’t guarantee compliance. Compliance depends on the organization’s requirements, controls, procedures, and data quality.

But there’s quite a difference between producing structured records with change history and saying:

“We believe this diagram is current.”

A centralized platform can support audit preparation with reports, access controls, documented relationships, and change history.

netTerrain includes audit-trail functionality for reviewing changes to infrastructure records and related user activity.

That’s more defensible than an undated drawing and verbal confirmation from the person who happens to remember the project.

The netTerrain audit trail helps teams review who changed an infrastructure record, what changed, and when the change occurred.

Person-Dependent Knowledge, Shared Documentation, and a System of Record

Operational Need	Person-Dependent Knowledge	Shared Documentation	System of Record
Onboarding	New employees depend on experienced staff	Employees review shared files	Employees navigate structured, connected infrastructure records
Outage response	Teams call people and reconstruct paths	Teams search diagrams and spreadsheets	Teams review documented paths, connections, and dependencies
Capacity planning	Availability is estimated from memory	Capacity is tracked manually	Capacity is associated with documented infrastructure
Change review	Changes are communicated informally	Files may be updated after the fact	Changes are recorded with relationships and history
Audit preparation	Teams rely on verbal confirmation	Teams produce static documents	Teams use structured records, reports, permissions, and change history

Shared documentation is an improvement.

A system of record goes further by connecting the data and relationships the team needs to operate the infrastructure.

Why OSP Fiber Makes the Problem Harder

These risks exist in almost any infrastructure environment.

In outside plant fiber networks, they become even harder to manage because much of the infrastructure is passive.

A discovery system may identify a router, switch, server, interface, IP address, or active network relationship.

It can’t look underground.

It can’t independently determine the complete physical state of every:

• Fiber strand
• Splice enclosure
• Patch panel
• Conduit
• Duct
• Handhole or manhole
• Air-blown fiber tube
• Physical route

It’s not that discovery is a problem.

It’s just not what discovery was designed to do.

A discovery tool may tell you that a device is responding. It can’t tell you that strand 47 was respliced into a different cable after an emergency repair.

That physical information must be modeled, imported, documented, and maintained.

OSP infrastructure also changes over time. Cables are rerouted. Strands are reassigned. Circuits move. New conduits are installed. Temporary fixes have a habit of becoming permanent.

When those changes never make it into the documentation, the gap between the recorded network and the real network grows with every project.

Eventually, somebody asks:

Where does this fiber actually go?

And nobody is entirely sure.

Discovery Is Important. It Is Also Not Magic.

That creates an obvious question:

Can discovery fill the documentation gap?

Discovery can help maintain information about active infrastructure, including:

• Routers, switches, servers, and other devices
• Ports and interfaces
• IP addresses
• Network relationships
• Device properties
• Hardware and software
• Status information from external systems

netTerrain supports discovery and data collection through connectors and technologies including SNMP, WMI, SSH, ping, the Collector, and the Integration Toolkit.

netTerrain discovery helps collect information about active infrastructure, including devices, interfaces, connectivity, properties, and status data from supported sources.

But discovery can’t automatically verify every passive cable, strand, splice, conduit, pathway, or patching relationship.

Asking a monitoring or discovery system to produce a complete fiber-plant record is a little like asking it to remember where the contractor buried the conduit.

Wrong tool. Wrong job.

The stronger approach combines discovered information about active infrastructure with maintained records of the passive and physical environment.

A Real-World Example: BWI Airport

This isn’t only a theoretical distinction.

Baltimore/Washington International Thurgood Marshall Airport had thousands of fiber connections across multiple sites, with much of that infrastructure knowledge managed by one person.

Its previous documentation platform took approximately 30 minutes to document a single circuit—an impractical process at that scale. After adopting netTerrain, BWI reported reducing that time to less than a minute while making fiber information available through a web browser instead of requiring employees to walk cable routes.

Just as importantly, the airport preserved the fiber manager’s accumulated knowledge for whoever eventually took over the role.

As BWI’s Dwayne Abrams explained in the BWI OSP case study:

“When I retire, I know that my work will be retained for the next person.”

The result wasn’t just faster documentation.

It was less dependence on one person’s memory.

What Should a Network System of Record Contain?

BWI’s experience shows what changes when infrastructure knowledge moves from one person’s memory into a maintainable operational record.

A useful system of record should bring information together—not become one more database the team has to check.

Depending on the environment, it should support:

• Physical and logical network views
• Hierarchical sites, buildings, rooms, racks, and equipment
• Devices, cards, ports, and connections
• Georeferenced OSP maps
• Conduits, ducts, trenches, and pathways
• Fiber cables and individual strands
• Splices and patching relationships
• Circuit paths and service dependencies
• Capacity and occupancy
• Discovery and external-system integrations
• Reporting and change history
• Role-based access and controlled updates

Notice that “make attractive diagrams” isn’t the objective.

Good diagrams matter. They make complicated infrastructure easier to understand.

But the real objective is to create an operational record the team can trust while planning a project, troubleshooting an outage, reviewing a change, or onboarding a new employee.

A diagram that looks good but can’t answer an operational question is decoration.

How netTerrain Helps Preserve Network Knowledge

The next step is to build and maintain this record without adding another disconnected system.

netTerrain helps teams maintain a shared system of record for network, data center, and outside plant infrastructure.

Discovery and integrations can help keep active-device information current. Structured documentation records the passive fiber, routes, circuits, splices, pathways, and history that discovery tools can’t find on their own.

For OSP and fiber environments, netTerrain can document:

• Fiber cables and individual strands
• Circuit paths
• Physical routes
• Splices and connectivity
• Conduits and pathways
• Air-blown fiber
• OSP infrastructure hierarchies

netTerrain supports fiber cables, strands, circuits, air-blown fiber structures, devices, ports, and related infrastructure objects.

Information can also be populated and maintained through imports, discovery, connectors, APIs, the Collector, and the Integration Toolkit. Supported import workflows include Excel, Visio, KML, KMZ, and ArcGIS-related processes.

The important part is the combination.

Discovery and integrations help collect information about the active environment.

Structured documentation provides the passive, physical, historical, and operational context that discovery can’t provide by itself.

One doesn’t replace the other.

Together, they create a more useful and maintainable picture of the infrastructure.

Doing Nothing Is Also a Decision

Organizations rarely decide, in a formal meeting, to make the network dependent on undocumented knowledge.

It happens one exception at a time.

A diagram isn’t updated because the team is busy.

A temporary circuit change is never recorded.

A spreadsheet is copied instead of corrected.

A new employee learns to ask the experienced engineer rather than consult the system.

Eventually, the unofficial process becomes the real process.

The cost then appears through:

• Longer incident investigations
• Delayed projects
• Repeat site visits
• Uncertain fiber capacity
• Inefficient expansion planning
• Dependence on a few employees
• Conflicting records
• More difficult audit preparation
• Lost knowledge when employees leave

None of these problems is dramatic on its own.

Together, they create an infrastructure environment that becomes harder to operate every year.

Your Network Shouldn’t Depend on Who’s Available

Keeping information in people’s heads can feel efficient.

Why update a formal record when you can ask the person who already knows?

Because every answer that isn’t documented creates another dependency.

And dependencies have a way of becoming visible at the worst possible time.

When an outage occurs, a new engineer joins the team, or a major infrastructure project begins, the organization shouldn’t have to find the one person who remembers what happened.

It should be able to look it up.

That’s the point of network documentation.

Not prettier diagrams.

Not more files.

Not another place to store data.

A dependable, shared record of how the infrastructure actually works.

Frequently Asked Questions

What is undocumented network knowledge?

Undocumented network knowledge is information about devices, connections, fiber routes, circuits, changes, and infrastructure dependencies that exists primarily in employees’ memories or disconnected records instead of a shared system of record.

What is the difference between shared documentation and a system of record?

Shared documentation may include diagrams, spreadsheets, and files available to the team. A system of record connects infrastructure data, relationships, routes, circuits, capacity, and changes in a structured environment that can be maintained and used operationally.

Why is undocumented knowledge especially risky in OSP environments?

OSP environments contain passive infrastructure such as fiber strands, splices, ducts, conduits, patch panels, and physical routes. These components can’t be fully detected through standard IP-based discovery, so the organization must maintain accurate physical records.

Can discovery document an entire fiber plant?

No. Discovery can identify active devices, interfaces, IP information, and certain network relationships. It can’t automatically verify the complete physical state of every cable, strand, splice, conduit, pathway, and patching relationship.

How does network documentation help during an outage?

Current documentation helps teams identify affected devices, circuits, fiber paths, connection points, services, and dependencies without reconstructing those relationships during the incident.

Does documentation software guarantee audit compliance?

No. Compliance depends on the organization’s requirements, controls, procedures, and data accuracy. Documentation software can support audit preparation through structured records, reports, permissions, and change history.

How did BWI Airport preserve its fiber knowledge?

BWI used netTerrain to document thousands of connections across multiple sites. The airport reported reducing circuit-documentation time from approximately 30 minutes to less than a minute while preserving the fiber manager’s knowledge for future employees.

How does netTerrain help preserve network knowledge?

netTerrain brings infrastructure diagrams, connectivity, OSP and fiber records, discovery information, integrations, reporting, and change history into a shared documentation environment.

Preserve Your Fiber Knowledge Before It Walks Out the Door

See how netTerrain can turn disconnected diagrams, spreadsheets, and person-dependent information into a shared system of record for network, data center, and OSP infrastructure— request a demo here.