Design-Driven Network Source of Truth

Introducing the Design-Driven Network Source of Truth: A New Era in Network Automation

Over the years, Network to Code has played a key role in transforming network operations, as automation shifted from a niche idea to a critical industry standard. This change was driven by the increasing scale and complexity of networks, demanding smarter, more efficient solutions. Central to this evolution has been the Network Source of Truth (NSoT)—a structured, consistent definition of the network intent (that may be spread across different data sources). Now, as the value of an NSoT is widely understood, NTC is advancing the concept with the design-driven NSoT. This next-generation approach redefines how NSoT data is created and used, aligning it with business goals to make network automation simpler, more effective, and highly scalable.

Note: This ties directly to the Network-as-a-Service (NaaS) mindset, which I discussed in detail earlier in this post.

From Network Diagrams to Configurations: Bridging the Gap

While visually compelling, traditional network diagrams often leave a gap between design and execution. Network architects meticulously craft these diagrams to illustrate how a network should function, but human interpretation is typically required to translate them into final configuration artifacts. Even with an NSoT, users must create objects that represent the architect’s intent, often managing deployment-specific details by hand. This process is not only inefficient but prone to errors, with minimal traceability to the original design.

The Promise of a Design-Driven NSoT

The design-driven NSoT addresses these challenges head-on by automating the transformation of high-level network designs into actual data objects that represent concrete deployments. It simplifies user input, enforces data consistency, and embeds quality checks directly into the process. For example:

• Standard data center design: Users provide minimal input, such as the T-size (small, medium, large) and the location. The design predefines all other decisions, like the number of leaf and spine devices, device types (selected dynamically from approved vendors), and interface connections.
• L3VPN service: Users specify locations to connect with the customer (auto-populated from an external CRM). The design determines the VRF, checks IP pool availability, and ensures compliance with network policies.

The 7 Principals of the Design-Driven NSoT

When we talk about the Design-Driven NSoT, we’re not just automating processes—we’re enabling teams to achieve more with less complexity, making self-service networks a practical reality. To harness its full potential, the design implementation must follow a set of guiding principles. Let’s break them down:

1. Meaningful Design

The output of the design must make sense to the user requesting it. While a deployment might rely on existing data, the design itself should be an intuitive entity that’s easy to understand. This clarity is vital when integrating with other automation processes, such as deploying configuration artifacts or monitoring the state of a design service. Instead of wrestling with unrelated metrics or logs, users can focus on the network service implemented through the design, offering a clearer vantage point than examining the network as a whole.

2. Simplicity in Usage

Less is more when it comes to user experience. A design interface that minimizes options while meeting customization needs ensures smoother workflows. By offering minimal yet intuitive input—with embedded data quality checks and dynamic decision-making—users enjoy a seamless interaction with the design process.

3. Complete CRUD Lifecycle

Every design deployment must support creation, read, update, and delete (CRUD) operations for holistic lifecycle management. Even if a design consists of thousands of objects or attributes, it should behave as a cohesive, unified entity. This principle ensures that design management remains efficient and intuitive, regardless of complexity.

4. Trackability for Accountability

Design deployment data must be trackable from both directions: the design instance perspective and the CRUD operation history. Changes—whether creating, updating, or deleting objects—must be documented comprehensively. This trackability provides reversibility, allowing users to move between different states while addressing potential data conflicts (akin to Git merges). This transparency ensures users always know how their designs have evolved over time.

5. Built-In Protection

Leveraging trackability, the design deployment data should be safeguarded against unintended changes. Hard-referenced data must remain immutable unless modified through a design CRUD operation. This protection mechanism ensures data integrity and prevents accidental misconfigurations.

6. Versioning for Evolution

Designs are not static—they evolve. Users should have the ability to manage multiple versions of a design in parallel. This functionality is crucial for rolling out new network services while maintaining the flexibility to iterate and refine designs as needs change.

7. Supporting Brownfield Environments

If you’re already managing your network based on design principles (and I hope you are!), you might wonder: what happens to all the existing network data that aligns with your design but wasn’t managed that way from the start? A practical design-driven solution should include an import mechanism to integrate this existing network data seamlessly. This feature simplifies the migration process, allowing you to transition from legacy environments to a modern, design-centric approach with ease.

The Design-Driven NSoT in Action

We’re thrilled to announce the Nautobot Design Builder release v2.1.0 incorporates these functionalities to enable a design-driven NSoT. Check out the release notes and documentation to get started.

The Nautobot Design Builder App has been empowering users for over a year, providing a flexible framework to populate data in Nautobot using standardized design files. Now, with the introduction of design lifecycle features, it evolves into a powerful enabler of the design-driven Network Source of Truth (NSoT), placing network architects’ designs at the heart of network automation.

Note: This new mode is fully backward-compatible with previous versions, allowing you to choose between traditional workflows and the new design-driven approach based on your use case.

By shifting the responsibility of data generation to network architects, the design-driven NSoT embraces a shift-left approach. Designs are built, tested, and validated using modern software development practices, including CI/CD pipelines and unit testing. This ensures designs behave as expected across a variety of scenarios.

The following figure illustrates how a single Design can serve as the foundation for multiple Design Deployments, each tailored with unique input data. This process results in concrete data implementation that can be reused and shared across various use cases, streamlining network automation and ensuring consistency.

The result? Self-service networks become a reality—services are automatically provisioned from pre-vetted designs, eliminating the need for manual approvals and significantly reducing the risk of errors. This new paradigm accelerates network automation adoption while maintaining consistency, quality, and scalability.

This approach is versatile and adaptable to a wide range of automation workflows because it prioritizes the data itself, rather than the specific method used to translate that data into configuration artifacts for the network infrastructure. For instance, in a GitOps-driven network automation workflow, the design-driven approach is the initial gateway, ensuring that network changes are simple, clear, and human-readable. From there, the changes can seamlessly integrate into a Git flow for version control and peer review or, if the network service is well-defined and deployment-ready, be pushed directly to the network without intermediate steps.

Another option, as described in the next figure, is to use the Nautobot Golden Configuration App to directly take the data for the design deployment and push the necessary configuration updates to the different devices involved in the design. 

This methodology bridges the gap between design intent and operational execution, streamlining automation while maintaining clarity and precision.

For a quick hands-on introduction, watch our Design-Driven Network Source of Truth video, where we guide you over the new features added to the Nautobot Design Builder App.