The Why, What, and How about Design-Driven Automation#

Christian Adell Querol, Network to Code

• Why: The most concrete instantiation of the keynote's thesis: treat design as executable, versioned, decommissionable data rather than documentation. Includes a working open-source implementation.
• What: A framework where a network service catalog (minimal validated inputs + template logic + external context) drives a PLAN, a builder creates tracked/connected/rollbackable data, and that service data becomes the single reference for orchestration, automation (Nornir/Ansible/Terraform engines), and observability.
• How: Demonstrated with Nautobot's Design Builder (which the speaker contributes to): a PoP deployment created from just name + size with architectural validation; a second design creating a VRF, prefix from a pool, and a cable; design updates that understand what changes (prefix preserved, cable re-pointed); clean decommissioning reverting created objects; and every change tracked as a commit. Key argument: test the design, not just the implementation — if the design is deterministic, deployments don't need per-instance review, the way nobody reviews a PR when someone launches a VPC.
• Where applicable: The demo is Nautobot-specific, but the concepts (minimal input, design-as-data, traceable provenance, dry-run, full lifecycle through decommission) port to other SoT platforms. Speaker is vendor-affiliated (Network to Code) yet the talk is substantially technique-first.