As we explored in a previous article, going live with a modern network information system feels like a real victory. But the morning after, the reality of daily operations often kicks in. Provisioning tickets, troubleshooting tasks, and maintenance requests arrive in steady succession. The answers to these requests are expected to be found within the new network information system.

In the era before the network information system, you would search for a map, find a file with a schematic drawing, and locate another file containing splice diagrams. You would then cross-reference those files and combine them with service information. Most of the time, this process was manual and slow, requiring an engineer to mentally combine different views of a network into single coherent image. However, it worked.

Now, with a modern system, you have a geographic view of your network for any area at your fingertips in seconds. This is ideal for seeing where cables run geographically and where customers, network devices, and closures are located.

But to provision a circuit or to resolve a physical network problem, one needs more than a map. One needs to see the network at the fiber and connector level, because that is where the essence of the network exists. An engineer needs to see how fibers are spliced along the trace path, which fibers are spare, and which are occupied. A geographic view is not designed to provide that specific type of insight.

You likely remember the promise of the new system: "Auto-generated single-line and splice diagrams." They were intended to complement the map view. By selecting a part of the network and pressing a button, you expected the system to generate high-level diagrams and end-to-end splice diagrams on demand, directly utilizing the up-to-date network inventory data.

It sounded perfect. The tool is there. The data is there. What could go wrong?

The "Generate schematics" button

You find and click the "Generate schematics" button in your network information system. Then you wait. After some time, the drawing appears on the screen. You are puzzled. What appears on the screen is not the clean, organized schematic drawing you used to create manually before the network information system had been introduced.

The connections visualized on the automated single-line diagram are difficult to follow. Lines representing connections are not straight; instead, most of them are bent with several corners. It seems the root cause for that is that the communication devices are not arranged optimally. There may even be cases where graphics overlap, thus making it hard or even impossible to understand the drawing.

When you dig deeper to solve your task, you require a splice view. However, all you may be able to create with the tool is an isolated tabular or graphical view of one specific closure, not an end-to-end visualization of a fiber path from point A to point B with all involved fibers and splices depicted. It is like using a flashlight in a dark room; you see only one spot at a time rather than using a main switch to illuminate the entire space. The functionality to generate an end-to-end splice diagram, showing the entire path from point A to point B including all the branches at the fiber and connector level rather than just one closure, is frequently lacking.

Why automated schematics underdeliver

The core requirement of any diagram is to be visually clear and easy to understand. If that is not the case, a time-tested wisdom says that you will probably make a wrong decision if you try to interpret it.

There are several reasons why automated schematic visualizations are often cluttered and as such are dangerous. First and foremost, it is inherently difficult to design and implement algorithms capable of managing white space at the level humans are capable of.

Network information system platforms often rely on generic graphing libraries designed for organizational charts or flowcharts. These libraries may treat a complex fiber network like simple lines and symbols on a graph, ignoring the deeply hierarchical or containment logic of telecom infrastructure. These generic graphing libraries often lack an understanding of telecom-specific logic.

As a result, these auto-generated schematics fail to meet the expectations of technicians. If they cannot understand the drawing immediately, at best the duration of provisioning or troubleshooting increases. At worst, the probability of a significant operational error rises because the automated diagram was misread.

When contemplating a digital transformation from file-based documentation to a modern system, the unique nature of telecom outside plant network documentation is often overlooked. File-based documentation was largely visual, not textual or tabular. In the past, technicians manually drew the network to represent it through:

• Maps to show physical location.
• Butterfly diagrams to visualize manhole ducts and cables.
• Single-line diagrams to show cable relationships.
• Splice diagrams to manage fiber-to-fiber connectivity.

During the data transformation project, these human-crafted drawings were converted into database records stored as numbers and text across many tables. In essence, that means that information-rich engineering drawings were reduced to numbers and text. This is a language computers understand. However, if a network is presented to us humans in such a tabular form, we struggle to understand it.

You assumed that once the network information system was in operation the "inverse operation," moving from database records back to human-readable drawings, would be seamless or a trivial task. While generating a map view of the network is a standard task for most network information systems because geo-coordinates of network elements have been explicitly captured and stored in the database, that is not the case for schematic views of your network. For those diagrams, locations of network elements and connections among them need to be calculated and are not captured from original human-made drawings and saved in the database during the data transformation project. That makes all the difference and from there stems the reliance on the algorithms we discussed above: they are responsible for calculating the positions of network elements and the connections among them.

Is your network information system capable of transforming numeric and text values into visually rich engineering drawings required by your technicians and engineering teams? That question may change how you look at a network information system.

If your engineers must still produce schematic and splice diagrams manually, thus very likely still creating the file-based network documentation you tried to eliminate in the first place, have your digital transformation goals been fulfilled? The answer is likely no. Faced with this reality, your team may struggle with the clutter and risk making wrong decisions, or do what they have always done: create schematics manually as in the past.

In my next post, I will demonstrate why manually creating or even editing and then saving changes applied to the initially automatically created diagrams is a trap that breaks the fundamental promise of a "single source of truth," which was the main goal of your digital transformation project.