Why Your Network Automation
Is Making Things Worse

There is a scene in the Wizard of Oz that has stayed with me for decades. Dorothy and her companions have finally reached the Emerald City. The wizard is revealed to be not a great and powerful entity at all — but a man behind a curtain, operating levers and switches that project an illusion of capability far beyond what actually exists. The controls work. The smoke and fire and booming voice — all of it works perfectly. But the underlying intent was never matched to the actual problem at hand.

I have been thinking about that scene for 25 years of network architecture work. I think about it every time I walk into an environment where automation is running flawlessly — executing, consistently, at scale — and producing exactly the wrong outcomes.

The levers are working. The man behind the curtain just hasn't asked whether they should.

The case for automation — and why it's incomplete

Let me be direct about what I am not arguing. Network automation is not optional. In any environment of meaningful scale — whether you are managing a multi-national MPLS backbone, a SMPTE ST 2110 broadcast facility moving uncompressed 4K video over IP, or a hybrid cloud environment spanning AWS, Azure, and GCP — manual configuration is simply not viable. The speed, consistency, and validation that automation provides are irreplaceable.

At Forward Networks, I built NetOps and SecOps automation solutions that reduced escalations by 80% and cut time to awareness and resolution by the same margin. I have written custom scripts that couple configuration analysis, ACL assignment, and physical connectivity into full-stack awareness — identifying WiFi SNR degradation, optimizing firewall ACLs, resolving BGP peering failures, and flagging out-of-date equipment with CVEs before anyone filed a ticket.

That automation worked because it was built around a question that most automation projects skip entirely: what is this network actually supposed to do, and is the automation aligned with that intent?

Most automation projects start from the wrong end. They start from the tool — what can this platform automate? — rather than from the outcome — what does this network need to reliably deliver, and what are the failure modes that would prevent that? The result is sophisticated machinery executing against an undefined objective. It runs. It scales. And when something goes wrong, it goes wrong everywhere simultaneously, and nobody can explain why because the automation did exactly what it was told.

What "intent" actually means in practice

Intent in network architecture is not a philosophy. It is a set of specific, answerable questions that must be resolved before any automation is designed, deployed, or expanded.

In my SMPTE ST 2110 work — designing IP networks for live broadcast facilities carrying uncompressed audio, video, and ancillary data — the intent questions were brutally specific. No two networks were the same, which meant no two automation frameworks could be the same either.

The right questions looked like this:

• What are the end nodes, and what are their NIC configurations? How many interfaces? Which carry PTP timing? Which are management-only?
• Is PTP isolated, or is it sharing links with multicast streams? Because the moment PTP shares bandwidth with media flows, your timing degrades and your entire production facility can go out of sync — frame by frame.
• Are your multicast groups being handled at Layer 2 with IGMP snooping, or routed at Layer 3? Because IGMP v2 knows nothing about bandwidth. It will saturate a backup path during planned maintenance and take down a live broadcast event without warning.
• What is the actual non-blocking fabric requirement for your leaf-spine architecture? Because "non-blocking" sounds like a specification, but oversubscribing your uplinks to the spine turns it into a very expensive bottleneck.

These are not abstract design questions. They are intent questions. Until you can answer them, you do not know what the network is supposed to do — and therefore you cannot automate it correctly. Automating before answering them does not accelerate delivery. It accelerates the propagation of incorrect assumptions.

The blast radius problem

A misconfigured ACL on a single firewall is a contained problem. A misconfigured ACL propagated automatically across 200 firewalls is an enterprise-wide security event — and in regulated industries like finance or healthcare, it is potentially a compliance incident that triggers HIPAA, PCI, CMMC, or NIST reporting obligations.

I have resolved exactly this category of failure. Black hole routes — where traffic is silently dropped because routing tables were updated consistently but incorrectly. Cross-security boundary access — where automation opened paths between network segments that should have remained isolated. ACL configurations that were syntactically correct but semantically wrong: they did what they said, but what they said was not what the security policy intended.

In each case, the automation was working. The intent behind it was not.

The 747 pilot — not the flight simulator

When I described my role at Forward Networks, I used the analogy of a 747 pilot — not someone who knows how to read the instruments and follow the procedures, but someone who understands how the plane is built, knows the path to arrive safely, and can re-engineer problems while in flight.

A flight simulator can replicate any scenario in a controlled environment. It runs perfectly, every time, against a known set of conditions. But it cannot handle a scenario it was not programmed for. It cannot look at an unexpected instrument reading and synthesize a response from first principles. It cannot say: "This is what the automation is telling me, but here is what I know about how this system actually works, and those two things are inconsistent."

That is the role of the human-in-the-loop in network automation — not to perform manual tasks that automation handles more efficiently, but to ensure that technical intent yields business success. The automation executes. The architect validates that what is being executed is actually what is intended.

This distinction becomes especially acute at the intersection of network automation and security. Governance, Risk, and Compliance frameworks — HIPAA, PCI, CMMC, NIST, CJIS, STIG, CIS — define requirements in terms of outcomes: data is protected, access is controlled, audit trails are maintained. They do not define which automation tools you use to achieve those outcomes. An automated environment that generates beautiful compliance reports but has a black hole route allowing unauthorized cross-boundary traffic has produced the appearance of compliance, not its substance.

What changes when you design for intent first

The shift is not architectural. It is methodological. It requires asking different questions before the first script is written.

In broadcast environments, I worked backwards from the end nodes — from the camera, the editor, the playout server — and built the network around what they required. Not what the switches could do. Not what the automation platform supported. What the content pipeline demanded: nanosecond-accurate PTP timing, non-blocking fabric for uncompressed 4K flows, isolated red and blue networks with SMPTE ST 2022-7 seamless protection switching, IGMP v3 source-specific multicast to prevent bandwidth exhaustion.

The automation followed from those requirements. It did not define them.

In enterprise security environments, I built tools that coupled configuration analysis, ACL assignment, and physical connectivity — because security intent spans all three layers simultaneously. A firewall rule that is correctly configured but applied to the wrong interface is not a security control. An ACL that accurately represents the policy document but does not account for a physical topology change is not a security control. Automation that checks each of these in isolation misses the failure mode that lives in their interaction.

The creative dimension — and why it matters for engineers

There is a version of this argument that stays entirely within the technical domain. But I want to make a broader point about how engineers approach complex systems — because it is relevant to why intent analysis is so consistently undervalued.

The Wizard of Oz was technically extraordinary. The flying monkeys — 300 miniature figures, each mechanically choreographed. The crystal ball sequences. The tornado sequence. The poppy field. Every single effect was a solved engineering problem. And yet the genius of it was not in the individual solutions. It was in the integration: understanding how all of these elements worked together to produce a coherent experience for an audience who would never see the machinery.

Network architecture at its best operates the same way. The routing protocols, the timing infrastructure, the security controls, the automation layer — each is a solved engineering problem. The question that determines whether the whole system works is whether someone understood how they needed to function together, in service of an outcome that the engineering alone cannot define.

That requires what I would call a creative technical mindset — the ability to hold both the specific mechanism and the overall intent simultaneously. To look at a BGP peering failure and understand not just the routing table entry that caused it, but what that failure means for the production schedule, the compliance audit, the live broadcast that goes out in four hours.

Automation handles the first part. The architect is responsible for the second. The wizard behind the curtain had spectacular machinery. What he lacked was someone willing to pull back the curtain and ask whether it was solving the right problem.

This is the synthesis of strategy, architecture, products, and action — where engineering intent and business outcome converge into a single, coherent design. The logik of what needs to happen, and the clarity of how to make it happen without compromise. That is what Synthlogik does.