Beyond Data: Why Design-Driven Automation is the Missing Link
Summarizing Christian Adell Querol's design-first methodology from AutoCon3
"We still live in this world," declared Christian Adell Querol, referencing Claudia de Luna's opening keynote about starting with design. "The designs are still there. However, we have to find a way where this design matches the automation."
His presentation built on Jaakko Rautanen's abstraction concepts, extending them to address a fundamental challenge: bridging the gap between network designs that exist in architects' minds and the automation systems that implement them.
The Data Disconnect Problem
While everyone agrees that "data is crucial in any automation strategy," Querol argued that understanding what we mean by "data" reveals complexity that justifies most networking jobs. Data can be intent, actual network state, configuration, operational metrics—"many dimensions. Data is a mess."
The core problem isn't data complexity itself, but how designs get "lost in translation" between conception and implementation. Network architects create diagrams and checklists to help engineers transform mental designs into reality, but meaning degrades through the process.
"We start with clear idea of what we want to implement on the network until we implement something, but we don't really know what we have implemented," he explained. "We can't even remember what was the purpose of a service we deployed one year ago."
The Service Vision
Querol's solution: "Why not make the network something that people understand at the level they need? They don't need to be network experts."
He shared a compelling example from 2016 when AWS offered only basic VPC networking. His team built a simple API for developers struggling to connect application islands—just specify application IDs and request connectivity. Three weeks before his AutoCon presentation, he discovered those developers still use that "crappy service" because it solved their actual problem with appropriate abstraction.
"Simplification is key. Simplification for your users. Not for you."
Design-Driven Data Properties
Effective design-driven automation requires data with specific characteristics:
Relationship Connectivity: Data belonging to the same service must be connected, enabling you to relate information together and propose different service versions.
Design Protection: When data follows design principles, it should be protected. "Who are you to go and change the implementation of a design? This should be protected."
Complete Lifecycle: Data must support creation, updates, and decommissioning through the full service lifecycle.
Purpose Assignment: Rather than disconnected data without relationships, design-driven approaches connect data through abstraction layers that represent what belongs together.
The Three-Role Architecture
Querol outlined clear responsibilities for design-driven automation:
Network Architect: Creates the logic for designs—the person "happy creating diagrams on whiteboards" becomes responsible for codifying that logic.
Network Engineering Team: Tunes how designs will be used in practice, handling implementation details and operational considerations.
Users: Interact with the simplest possible interface for the services they need, from VPN deployments to complete data centers.
Even simple services require "dozens, hundreds, thousands of objects"—massive data complexity hidden behind simple interfaces.
The Technical Architecture
Querol's implementation uses three building blocks:
1. Inputs
"What we're going to expose to users. The fewer, the better. If you can expose two inputs, better than 10." These inputs include constraints and validations while remaining user-friendly.
2. Templates
"How you explain your logic. This could be Python, Go, Jinja templates, whatever. It's up to you to decide how you feel comfortable." The code transforms user inputs into comprehensive service implementations.
3. Context
"You're not isolated on one island. You have to interact with service ticketing, external systems, whatever." Context handles real-time interactions, reservations, and integrations outside the core logic.
The Plan-Build-Service Workflow
Plan Generation: When users run a design with input parameters, the system combines logic and context to render a plan—"like the architecture blueprint that engineers transform from whiteboard diagrams into specific plans."
Builder Execution: The plan becomes actionable through a builder that creates all necessary data (IP addresses, racks, devices, everything) while following critical rules:
Idempotency: Same inputs produce same results
Rollback capability: If any of 1,000 objects fail, everything rolls back automatically
Protection enforcement: Prevents unauthorized changes to service-owned data
Service Implementation: The service represents "all the data created for some purpose" with lifecycle tracking, versioning, and ownership.
The Automation Integration
Design-driven services become the foundation for simplified automation architecture:
Service Changes → Orchestration: When services change, orchestration stitches together the necessary tasks. If a service touches 10 devices, orchestration triggers 10 automation tasks.
Targeted Infrastructure Changes: "You're deploying a service. You're changing your infrastructure not as a whole—just the minimum infrastructure that depends on this service definition."
Service-Centric Observability: "Your users don't care about interface traffic. They care about the service they requested. If your user requested a BGP session, tell him the BGP session is established."
Starting Small, Growing Compound Interest
Querol addressed the common objection that only hyperscalers can implement such approaches: "You can start with something very small, very simple."
The key is compound interest—start with basic services and incrementally add details until achieving something comprehensive. "Focus more on the design because the design is the important part. If you get right on the design and your design is idempotent, you will do always right."
Brownfield Integration
For existing networks, Querol advocated an import functionality: "You have to not leave anyone behind. If possible, bring all the services you have already in place into this new approach of design-driven."
This acknowledges that most organizations can't start from scratch—they need migration paths for existing infrastructure that hopefully followed design standards.
Implementation Principles
Test Your Design, Not Just Your Network: "Focus more on the design because the design is the important part... If you get the design right and your design is idempotent, you will always do right."
Modular Service Collections: "Break your network into a collection of modular services. How many? Doesn't matter. But start by one."
Data Ownership: At the attribute level, only one design can own an attribute. Other designs can reuse attributes, but ownership remains singular to prevent conflicts.
The AI Integration Question
When asked about adding AI abstraction layers, Querol referenced recent announcements about AI tools for creating automation logic: "You can use any kind of tool that helps you to create this logic. But at the end, you have to own... you have to take ownership to implement the logic."
The point: AI can assist with design creation, but humans must maintain ownership of the implemented logic to ensure consistency and reliability.
Why This Matters
Querol's design-driven approach addresses a fundamental automation challenge: the gap between what network architects envision and what gets implemented. By codifying design logic and protecting design-driven data, organizations can ensure that automation implementations match architectural intent.
This represents an evolution beyond basic automation tooling toward systematic design implementation. Rather than automating existing manual processes, design-driven automation encodes the thinking behind those processes, ensuring consistent implementation regardless of who operates the system.
The approach also acknowledges organizational realities—architects, engineers, and users have different needs and capabilities. By creating appropriate abstraction layers for each role, design-driven automation enables specialization while maintaining system coherence.
As Querol concluded, this isn't tool-specific thinking—it's "a mindset that I really encourage you to adopt." The future of network automation may depend less on better tools and more on better ways of encoding and implementing design intent.
Watch the full presentation: The Why, What, and How about Design-Driven Automation
