InfoWorld recently published a series by Adnan Masood on what it takes to move generative AI from promising pilots to dependable production systems. The core argument has nothing to do with models: enterprise AI fails in the gap between demo and production because nobody applies operational discipline. No reliability engineering. No ownership. No evaluation. No way to measure whether the thing actually moved a business number. The prescription is to treat GenAI like a production service — with contracts, monitoring, and accountability.
Now swap out GenAI and insert network visibility, and the argument lands just as hard.
Most IT organizations run network discovery exactly like a failed AI pilot: as a one-time project. Someone built a Visio diagram in 2021. Someone runs a scanning tool before the annual audit. The map starts decaying the week it is finished. And when a warehouse access switch dies at 6:45 a.m., the first system to detect the outage is a user in operations submitting a ticket that says the internet is down.
If you have ever traced cables at 2 a.m. because your monitoring tool had nothing to say about the failure, this one is for you.
The Problem in Depth
Every tool sees a slice. Nobody sees the network.
Look at the stack most IT teams run:
- Standalone NMS tools poll a device list that was imported once and refreshed on a cron — weekly at best, quarterly in reality. They monitor what they already know about and stay silent about everything else.
- RMM platforms — NinjaOne, ConnectWise Automate, Datto RMM — see the world through agents. Servers and workstations with the agent report in. The printer in marketing, the IP cameras in the loading dock, the access points, and the unmanaged switch someone added under a desk do not exist as far as the RMM is concerned.
- The helpdesk records the symptom — cannot reach the ERP — with zero infrastructure context. The technician sees a user complaint, not a topology.
- The network diagram is a Visio file last touched by an admin who left the company 18 months ago.
Each tool is individually defensible. Together they guarantee that when infrastructure actually fails, the humans assemble the picture manually, under pressure, from four systems that do not share a single device identity.
Why the gaps exist
Three structural reasons, and none of them are fixed by buying another point tool:
- Discovery is batch, not event-driven. Legacy network management was designed around scheduled scans — run nightly, run quarterly. A device that appears and a link that drop exist in a window of blindness until the next cycle. The physical network changes continuously; your visibility model changes in batches.
- The stack is siloed. Monitoring, RMM, helpdesk, and documentation live in separate databases with separate ideas of what a device even is. So the alert in the NMS never becomes a ticket in the helpdesk automatically, and the ticket never carries the topology.
- Nobody owns the map. The four-disciplines framework is blunt about this in the AI context: systems without owners do not reach production. Same rule here. The diagram is everyone's job, so it is nobody's job, so it is wrong.
Then there is the unmanaged layer. In a typical mid-size office, a huge share of devices on the wire have no agent and no monitoring: printers, IP cameras, door controllers, conference-room equipment, and the retail-grade switch an employee installed because port density was inconvenient. Those devices consume switch ports, DHCP scope, and your patience — and they are invisible to an agent-based RMM.
What it actually costs: a scenario every sysadmin recognizes
A 48-port access switch in the warehouse fails at 6:45 a.m.
- 6:47 — First ticket: a user cannot open the ERP.
- 7:10 — Fourteen tickets in. The helpdesk lead walks over to the network admin's desk.
- 7:10–7:35 — Identification. The diagram says Warehouse A — IDF, but rack labels changed during last year's remodel. Remote into the core, read the ARP table, check neighbor discovery, call the warehouse manager to describe the blinking lights.
- 7:35 — Root cause found: dead access switch. 40+ users have been offline for 50 minutes.
Roughly 25 of those minutes — plus the 23 minutes before IT even knew — were pure visibility failure. Live topology would have compressed detection to seconds and identification to a glance. That is an hour of 40 people's productivity per incident, and warehouse incidents do not happen once a year.
The MSP version stings differently: the client calls your NOC to report the outage. When the customer knows before the provider does, no SLA percentage repairs the trust damage.
And there is a reporting tax. Because monitoring data and ticket data live in separate systems, your SLA report measures response time from ticket creation. The 23 minutes users spent diagnosing your infrastructure for you are invisible. Your MTTD — the metric that actually shows whether monitoring works — does not exist in your reporting, because computing it requires data from two platforms that do not talk.
How AlertMonitor Solves This
This is the same discipline the InfoWorld series demands of AI — run it as a service, with discovery that never stops, events instead of batches, clear ownership, and measured outcomes — applied to the network fabric.
Continuous, always-current discovery. AlertMonitor discovers and maps every device on the network — switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints — using SNMP, ARP, and active scanning. Not a quarterly job: a continuously running service. The live topology map reflects the real network state right now, including every device no agent will ever see.
Event-driven alerts with full context. When a switch goes offline, a link drops, or a new device appears, an alert fires instantly — and it arrives with network context: which device, where it sits in the topology, what its uplink is, and what is downstream of it. You skip the identification phase entirely, because the alert is the identification.
The workflow changes shape.
Old way: user ticket → reproduce the symptom → guess the segment → remote into the core → read ARP output → call somebody to look at a rack → resolve.
AlertMonitor way: topology alert at 6:45:20 → map shows the failed switch, its location, and the 41 downstream devices → ticket auto-created with that context attached → tech confirms power, dispatches or fails over → resolved. Detection in seconds. Triage in minutes.
One platform, not four. The alert is already a ticket. The affected device's RMM data and patch status are a click away, not a login away. For MSPs, the NOC view spans every client, so a dead switch at Client 7 pages you before Client 7's office manager notices the card reader is down.
And the measurement finally works. When detection and resolution live in the same system, MTTD and MTTR come from one dataset — real numbers for the IT manager who is tired of assembling SLA reports from three exports and a spreadsheet.
Practical Steps You Can Take Today
1. Find out how stale your inventory really is. Pick five devices in your current diagram. Physically verify one. Compare the documented IP of a core switch with reality. If your error rate on five devices is even one, the full map is worse.
2. Turn SNMP on everywhere it matters — and verify it. Discovery is only as good as what devices will tell it. Confirm SNMP is actually running on your Windows Server fleet:
$servers = Get-Content "C:\Inventory\servers.txt"
Invoke-Command -ComputerName $servers -ScriptBlock {
Get-Service -Name "SNMP","SNMPTRAP" -ErrorAction SilentlyContinue |
Select-Object PSComputerName, Name, Status, StartType
} | Format-Table -AutoSize
Anything that comes back empty needs the SNMP service installed and a locked-down community string before it can be monitored properly.
3. Baseline your subnets so new devices stand out. Even before you have live topology, snapshot the ARP table and diff it a week later:
# Snapshot the current ARP table for the 192.168.20.0/24 segment
Get-NetNeighbor -State Reachable,Stale,Permanent |
Where-Object { $_.IPAddress -like "192.168.20.*" -and $_.LinkLayerAddress } |
Select-Object IPAddress, LinkLayerAddress, State |
Export-Csv "C:\Inventory\arp-baseline.csv" -NoTypeInformation
# A week later: find devices that appeared since the baseline
$known = (Import-Csv "C:\Inventory\arp-baseline.csv").LinkLayerAddress
$current = Get-NetNeighbor -State Reachable,Stale,Permanent |
Where-Object { $_.IPAddress -like "192.168.20.*" -and $_.LinkLayerAddress }
$current | Where-Object { $_.LinkLayerAddress -notin $known } |
Format-Table IPAddress, LinkLayerAddress, State
Every line in that second output is a device nobody documented — a new laptop, an unmanaged switch, a camera. In AlertMonitor, this comparison runs continuously and raises an alert the moment an unknown device appears, not a week later when someone remembers to run a script.
4. Health-poll your critical infrastructure directly. A 30-second sanity check on a core switch, useful before and after any platform is in place:
# Quick health check on a core switch
snmpget -v2c -c <community> 192.168.10.2 sysDescr.0 sysUpTime.0
snmpwalk -v2c -c <community> 192.168.10.2 IF-MIB::ifOperStatus
A sysUpTime measured in minutes on a switch that should have months of uptime means it rebooted — and that alone explains a world of intermittent symptoms.
5. Give the map an owner, the way a service has an on-call. Name the person accountable for topology accuracy. Route topology-change alerts — device down, link drop, new device — to a channel a human actually watches, not a mailbox nobody reads.
6. Measure the whole workflow, not the tool. Start tracking time-to-detect separately from time-to-resolve. If you cannot compute MTTD today, that is the gap. Once monitoring and helpdesk share one dataset, the report takes minutes instead of a week of exports.
The Takeaway
Generative AI is not failing in enterprises because the models are weak, and your network visibility is not failing because SNMP is weak. Both fail for the same reason: they were built as projects instead of run as services. A diagram is a project artifact. A live map with instant, contextual alerts is a production service — continuous discovery, event-driven response, clear ownership, and numbers that prove their worth in seconds saved and outages caught before the first ticket.
Your users should never be your monitoring system. The switch should file the first ticket.
Related Resources
AlertMonitor Network Monitoring & Visibility AlertMonitor Platform Overview Book a Demo Network Monitoring & Visibility Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.