Network automation often starts at the build phase of the familiar design → build → operate workflow, after the architecture decisions have already been made.
Engineers design the network, work out how to build it, then automate parts of the implementation. The design lives in Visio, Word, spreadsheets, or someone’s head but not in the automation system itself.
That separation leaves useful information behind. A script might know which interfaces need BGP configuration without knowing which design requires those connections. When the network changes, engineers have to recover that context before they can update the implementation.
Design-driven automation brings architecture decisions into the automation system.
It represents the design as structured data and keeps it connected to the infrastructure derived from it. That gives your automation a higher-level starting point and a reference it can keep using throughout the network’s life.
What is design-driven automation?
Design-driven automation starts with business and technical requirements, uses them to define the network or infrastructure design, then derives the low-level implementation from that design.
It helps to think of design-driven automation in three layers:
- Design: The reusable rules and model that describe how the infrastructure should work
- Inputs: The variables that define a particular instance of the design
- Implementation: The devices, interfaces, addresses, and other objects derived from the design and inputs, along with configuration, documentation, and tests
The inputs deserve particular attention. In his AutoCon 3 presentation, summarized on the Network Automation Forum blog, Christian Adell emphasized exposing as few inputs to users as possible. The design logic handles the implementation details, so users only need to supply the information required to define their particular service or infrastructure.
Consider a leaf-spine fabric. The design defines the topology, device roles, connection rules, and addressing strategy. The inputs identify the site and specify how many leaf switches it needs. Automation uses both to create the detailed implementation.
Engineers still make the architecture decisions, but those decisions get captured in a form the system can apply repeatedly by simply entering different inputs for different sites.
The connection between the three layers stays intact, so it’s possible to trace a generated device or link back to the fabric instance and design that produced it, even long after the initial build.
Automate the translation from design to implementation
Design-driven automation lets teams work with a design and its inputs instead of specifying each implementation step.
For example, in a procedural workflow, you might tell a script to create two switches, allocate addresses, define interfaces, and establish BGP sessions. The script speeds up work you would otherwise do manually.
In a design-driven workflow, you might declare that a site uses a particular fabric design with a specified number of leaf switches. The system translates that declaration into the infrastructure objects the design calls for.
The translation still requires logic. Someone has to define how device roles map to connections, how addresses are allocated, and which constraints apply. But once captured in a reusable process, that logic can be applied consistently across sites.
This is where the distinction between declarative and imperative automation becomes relevant. An imperative workflow asks you to specify actions. A declarative workflow asks you to describe the desired state and leaves the system to determine the changes needed.
For ongoing use, the workflow also needs idempotency. If you run the process again with unchanged inputs, it should preserve the intended implementation, including existing address allocations. Otherwise, a routine rerun could introduce an unintended network change.
Preserve the context that automation traditionally loses
Keeping the design connected to what gets built makes architecture decisions available to automation after deployment.
During design, engineers decide how the network should work, then translate those decisions into devices, connections, and resource allocations during the build. But once the network is in operation, teams traditionally see the resulting configuration with little structured information about where it came from.
A BGP session tells you that two devices exchange routes. By itself, it may tell you very little about the service it supports or the design rule that requires it. You can investigate, of course, but every investigation takes time and depends on finding the right document or colleague with the answer.
When the relationships are instead explicit, automation can follow them. For example, tracing a link to the fabric implementation it belongs to, the design version that implementation follows, and the services that depend on its connectivity.
With those dependencies captured, you can identify which services a proposed change affects, check whether an implementation follows its assigned design, and find sites still using an older version.
Capturing design as data takes work, but the payoff is that the context becomes queryable and reusable. Your team no longer has to reconstruct the same relationships every time it reviews a change.
Explicit design context also gives AI agents more useful information to work with. They can follow modeled relationships and constraints instead of inferring architectural intent from configuration alone.
Make Day 2 part of the design
A reusable design process supports changes well beyond the initial deployment.
One-time provisioning scripts often collect inputs, create infrastructure, and leave the generated objects behind. If the original inputs and relationships disappear, later changes need a separate process that understands what the first script did.
But in a design-driven workflow, to expand a fabric from six leaf switches to eight, for example, you simply update the desired leaf count. The system then recalculates the implementation and identifies the additional devices, links, and allocations required by the design. Existing allocations remain stable.
The same principle applies when the design itself changes. If a new version updates a connection rule, the system can derive the expected implementation and compare it with the current one.
There are two useful comparisons here:
- Comparing implementation data with its design reveals design drift, that is, differences between the implementation and the design it should follow.
- Comparing intended configuration with observed network state shows whether the deployed network matches the intended implementation.
Together, those comparisons let you follow a change from the design through to the running network.
How is intent-based networking related?
Design-driven automation overlaps with intent-based networking and declarative automation, but the terms emphasize different parts of the work.
The Internet Research Task Force’s RFC 9315 describes intent as the operational goals and outcomes you want, expressed without prescribing how to implement them.
Intent-based networking (IBN) includes translating those goals into network behavior and checking whether the network continues to satisfy them.
Intent-based automation applies that outcome-oriented idea to automation more generally.
Declarative automation describes how you interact with the system: Specify the desired state and let the system work out how to reach it. You’ll also see declarative network automation used when the declarative model is applied specifically to networks.
Design-driven automation focuses on capturing the design that connects higher-level requirements to concrete infrastructure and keeping that connection intact.
Design-driven automation can provide the design and implementation context an intent-based networking system needs. An IBN system must also check whether the running network delivers the intended outcomes and respond when it falls short.
Design and configuration checks can support that work but matching a design doesn’t necessarily mean the network meets its operational goals.
Your source of truth needs to capture design
When design becomes an input to automation, your data system needs to represent more than devices and addresses.
For our fabric example, that means storing the fabric instance, its inputs, the generated technical objects, and the relationships connecting them. You also need to know which design version produced the implementation.
A data model that’s limited to an asset inventory leaves the higher-level decisions elsewhere. Your schema needs room for devices but also for the concepts your team designs around, such as fabrics, service offerings, or standard site designs.
The data model also needs to support the logic that turns design into implementation, keeping the resulting objects connected to their inputs.
Beyond the data model, version control and continuous integration in your source of truth can help safely manage infrastructure change at scale. They aren’t hard requirements for design-driven automation, but they let you preview the impact, run automated checks, and review changes before deployment.
Automate from the design down
A design-driven approach pulls automation back to the very start of the design → build → operate workflow. The architecture decisions that shape your network become part of the system, staying connected to the infrastructure they produce as it’s built and operated.
That continuity is essential when the network needs to change. Both engineers and automation can refer back to the design, understand how the implementation follows from it, and assess what needs to evolve. The design remains a working reference throughout the network’s life.
