Start at the Beginning: Why Network Automation Needs Better Foundations
Summarizing Claudia de Luna's opening keynote from AutoCon3
In a refreshingly honest keynote that felt more like a fireside chat than a typical conference presentation, Claudia de Luna challenged the network automation community to step back and examine how we got here—and whether we're solving the right problems.
The Problem: We Started in the Middle
De Luna's central argument is that network automation jumped straight into operations without laying proper groundwork. While other IT domains moved to controller-based architectures, networking remained fragmented, leading us to embrace automation without asking fundamental questions:
Why is automation the right solution for networking specifically?
How does networking differ from cloud environments where automation succeeded?
What requirements are we actually trying to meet?
"We went from network automation with a little 'n' and little 'a' to Network Automation with capital letters," de Luna observed, "but really, what we've been talking about all this time is software development."
The Missing Foundation: Requirements and Design
Drawing from her experience at NASA's Jet Propulsion Laboratory, de Luna emphasized how requirements drive successful projects. Her story about presenting a structured cabling plan to a board of literal rocket scientists (including the feared-and-revered Dick Matheson) illustrated how proper requirements, clear design rationale, and systematic thinking create unshakeable foundations.
The problem? Network automation started with operations—sources of truth, Python training, and tool selection—while skipping the design phase entirely.
"Someone had to build something for us to operate it," she reminded the audience. "We forget that part."
The Design-Operations Chasm
One of de Luna's most practical insights addressed the inevitable split between design and operations teams. She's seen this pattern repeatedly: operations teams are too busy keeping things running to design the future, but when design teams split off, they create solutions operations can't support.
Her solution from JPL days: ensure design teams spend time in operations ("answering the calls from users") and maintain clear handoff processes throughout the project lifecycle. Bridge the chasm intentionally, or it will become permanent.
The Career Crossroads
In perhaps the most personal moment of the talk, de Luna shared her own professional dilemma: "I spend more time supporting software we've developed than configuring routers and switches. Is that where I want my career to go?"
This resonated deeply with an audience facing the same choice. Can someone be exceptional at both network engineering and software development? Should network engineers learn Python, or should teams hire actual developers?
Her answer: "Both disciplines are deep. I worry I can be a good network engineer and an OK scripter, but can I do both jobs adequately?"
Practical Takeaways
Rather than prescribing specific tools or methods, de Luna offered a framework for better decision-making:
The Four Essential Questions:
How will this product/service help provide the solution?
What are the other options?
Who will implement the solution?
How will we support it?
Focus on Business Problems: Instead of asking "how do we do network automation," ask "what business problem is causing our users grief, and how might automation help solve it?"
Distinguish Personal vs. Enterprise: Is this automation for personal productivity (making your job easier) or enterprise impact (delivering better service to the business)?
The Path Forward
De Luna's vision involves starting with programmatically consumable design data—creating the "source of truth" at the beginning rather than debating where to find it later. This requires building new muscle memory for network engineers: starting projects not with blank Visio diagrams, but with structured data that feeds the entire automation pipeline.
"We need basically legs and upper body," she concluded. "We want to be the superheroes of our enterprises... but the exercise equipment isn't going to give you the superhero physique. You are."
Why This Matters
This keynote landed because it addressed the elephant in the room: despite years of progress, many network automation initiatives still feel fragmented and disconnected from clear business value. De Luna's message wasn't about specific tools or techniques—it was about stepping back, asking better questions, and building stronger foundations.
For teams just starting their automation journey, this provides a roadmap. For veterans feeling lost in the middle of their transformation, it offers perspective and direction.
The network automation community has proven it can build impressive technical solutions. Now, as de Luna suggests, it's time to ensure we're building the right things, for the right reasons, in the right order.
Watch the full presentation: AutoCon3 Opening Keynote
