The Need

Every time a new building needed a network, it was weeks of spreadsheet work. Engineers manually picking devices, calculating port counts, figuring out cabling, assigning IP addresses by hand. The same work, repeated hundreds of times, with a different person making slightly different decisions each time.

We asked ourselves: what if we could describe a building in 20 lines of YAML and have the entire network design generated automatically? Every cable, every port assignment, every IP address, every ordering file. Consistent. Repeatable. Auditable. That is what Fleet-as-Code does.

What is Fleet-as-Code

A fully automated, policy-driven platform that transforms a simple YAML description of a building into everything needed to deploy a complete enterprise network. Hardware ordering, physical cabling, IP addressing, Day-0 device configuration. All generated from policy.

How we Solved

graph LR
    subgraph "Traditional Approach"
        direction TB
        M1[Weeks of manual BOM creation]
        M2[Error-prone cable spreadsheets]
        M3[Inconsistent standards across sites]
        M4[IP planning by hand in Excel]
        M5[No audit trail or repeatability]
    end

    subgraph "Fleet-as-Code"
        direction TB
        A1[BOM generated in seconds]
        A2[Every cable auto-calculated]
        A3[Enterprise policy enforced everywhere]
        A4[IP plan auto-allocated from IPAM]
        A5[Full Git history and governance]
    end

    M1 -.->|Replaced by| A1
    M2 -.->|Replaced by| A2
    M3 -.->|Replaced by| A3
    M4 -.->|Replaced by| A4
    M5 -.->|Replaced by| A5

Core Principles

These are the principles that drive every design decision in the platform:

Principle What It Means in Practice
Declare Intent A site input says “I need 96 ports on floor 1” not “give me 2 stacks of C9300-48T”
Encode Once Device specs, topology rules, VLAN schemas live in YAML policy files. Change them once, every future site picks them up.
Fail Loud If a port count exceeds what a stack can serve, the build fails with a clear error. It never silently under-provisions.
Deterministic Run the same input today or six months from now. You get the same BOM, same cables, same IPs.
Traceable Every generated artifact lands in Git. Every site goes through governance approval before ordering.
Humans Define, Machines Execute Network architects write topology policies. The engine does the multiplication, the port math, the cable selection.

How It Works

flowchart LR
    A["DEFINE
Simple YAML input
~20 lines of config"]
    B["GENERATE
Policy engine builds
everything automatically"]
    C["DELIVER
BOM, cables, IP plan,
Day-0 templates"]
    D["DEPLOY
Order, build, provision
with confidence"]

    A --> B --> C --> D

    style A fill:#1565c0,color:#fff
    style B fill:#2e7d32,color:#fff
    style C fill:#ef6c00,color:#fff
    style D fill:#6a1b9a,color:#fff

Platform Architecture

graph TB
    subgraph "Fleet-as-Code Engine"
        ENGINE["Policy-Driven
Generation Platform"]
    end

    subgraph "Enterprise Standards"
        POLICIES["Topology Policies
Device Catalogs
Address Schemas"]
    end

    subgraph "Network Platforms"
        CATC["Cisco Catalyst Center"]
        IPAM["IPAM"]
    end

    subgraph "Enterprise Systems"
        SNOW["ServiceNow
(Change Mgmt)"]
        GITHUB["GitHub
(Artifact Store)"]
    end

    POLICIES -->|"Standards and
device rules"| ENGINE
    ENGINE -->|"Day-0 templates"| CATC
    ENGINE -->|"Subnet allocation"| IPAM
    ENGINE -->|"Change requests"| SNOW
    ENGINE -->|"All outputs"| GITHUB

    style ENGINE fill:#1a73e8,color:#fff
    style POLICIES fill:#ff6d00,color:#fff
    style CATC fill:#049fd9,color:#fff
    style IPAM fill:#049fd9,color:#fff
    style SNOW fill:#6b4fbb,color:#fff
    style GITHUB fill:#24292e,color:#fff

The Generation Pipeline

sequenceDiagram
    participant Input as Site YAML
    participant Policy as Policy Engine
    participant BOM as BOM Builder
    participant Conn as Connectivity Builder
    participant Net as Network Planner
    participant Out as Outputs

    Note over Input,Out: Fully Automated, No Human Intervention Required

    Input->>Policy: Building requirements (floors, ports, services)
    Policy->>Policy: Resolve topology + device selection rules

    rect rgb(230, 245, 255)
        Note over Policy,Out: Stage 1: Materials
        Policy->>BOM: Apply device selection + stack sizing
        BOM->>Out: BOM CSV + CCW ordering file
    end

    rect rgb(230, 255, 230)
        Note over Policy,Out: Stage 2: Physical Build
        Policy->>Conn: Resolve ports, cables, power, console
        Conn->>Out: Connectivity CSV + Rack diagrams + Topology SVG
    end

    rect rgb(255, 245, 230)
        Note over Policy,Out: Stage 3: Logical Build
        Conn->>Net: Device inventory + address blocks
        Net->>Out: Network plan + Address table + CATC templates
    end

    rect rgb(245, 230, 255)
        Note over Policy,Out: Stage 4: Publish
        Out->>Out: Push all artifacts to GitHub + governance docs
    end

From Input to Output: An Example

flowchart LR
    subgraph "INPUT (20 lines)"
        YAML["site_name: SITE-ABC
topology: standard_enterprise
floors:
  - floor: 1
    rooms:
      - type: BD
        ports: 96
        aps: 12
      - type: FD
        ports: 48
        aps: 6
services: [voice, wireless]"]
    end

    subgraph "OUTPUT (All artifacts)"
        direction TB
        O1["47 devices with PIDs"]
        O2["200+ cable connections"]
        O3["94 power assignments"]
        O4["32 VLANs with IPs"]
        O5["Day-0 config templates"]
        O6["Rack + topology diagrams"]
    end

    YAML --> O1
    YAML --> O2
    YAML --> O3
    YAML --> O4
    YAML --> O5
    YAML --> O6

    style YAML fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    style O1 fill:#f3e5f5,stroke:#7b1fa2
    style O2 fill:#f3e5f5,stroke:#7b1fa2
    style O3 fill:#f3e5f5,stroke:#7b1fa2
    style O4 fill:#f3e5f5,stroke:#7b1fa2
    style O5 fill:#f3e5f5,stroke:#7b1fa2
    style O6 fill:#f3e5f5,stroke:#7b1fa2

What Gets Generated

mindmap
  root((Site Input
~20 lines YAML))
    Materials
      Bill of Materials CSV
      CCW Ordering File
      DHCP Scopes
    Physical Build
      Connectivity Matrix
      Rack Elevation Diagrams
      Network Topology SVG
      Port Maps
    Logical Build
      Network Plan (L2/L3)
      Address Table
      CATC Day-0 Templates
      CMDB Attributes
    Documentation
      Governance Slide (PPTX)
      Site README
      Pipeline Events

Key Capabilities

Capability Description
Policy-Driven Design Enterprise standards encoded once, applied everywhere automatically
Multi-Topology Support Small offices, standard enterprise sites, multi-building campuses, all from one engine
Complete Physical Build Every cable, port, PDU socket, and console connection calculated
IP Address Automation Subnets allocated from IPAM with profile-based VLAN assignment
Day-0 Provisioning Catalyst Center composite templates generated for zero-touch deployment
Governance and Compliance Full audit trail via Git, governance slides for PM approval
CCW-Ready Ordering Direct import to Cisco Commerce Workspace for hardware procurement
Visual Documentation Auto-generated rack elevations and topology diagrams (SVG)
Topology Inheritance Base topologies extend via overlays. Maintain once, deploy variants.
Fail Loud, Never Guess Validation at every step ensures no incorrect hardware ships

Scale and Flexibility

graph TB
    subgraph "One Platform, Many Site Types"
        SMALL["Small Office
Single WAN router, no core
One access stack"]
        MEDIUM["Standard Enterprise
Redundant WAN, dual core
Multi-stack access layers"]
        LARGE["Multi-Building Campus
Campus backbone
Satellite building links"]
    end

    ENGINE["Fleet-as-Code
Same engine, same policies"] --> SMALL
    ENGINE --> MEDIUM
    ENGINE --> LARGE

    style ENGINE fill:#1a73e8,color:#fff
    style SMALL fill:#e8f5e9,stroke:#2e7d32
    style MEDIUM fill:#fff3e0,stroke:#ef6c00
    style LARGE fill:#fce4ec,stroke:#c62828

The same policy engine handles all of these. The only difference is the topology file selected in the site input. Device selection, stack sizing, cabling, addressing: all derived from that single choice.

Business Value

mindmap
  root((Fleet-as-Code))
    Operational Efficiency
      90% faster site deployment
      Seconds vs weeks for BOM generation
      Zero manual spreadsheet work
    Risk Reduction
      Policy-enforced accuracy
      No human calculation errors
      Validated at every step
    Consistency at Scale
      Hundreds of sites, one standard
      Enterprise-wide compliance
      Topology policies maintained once
    Agility
      Infrastructure as Code
      Repeatable and auditable
      Rapid topology iteration

Summary

Fleet-as-Code transforms network site deployment from a manual, weeks-long engineering effort into a fully automated, policy-driven generation pipeline. Organizations deploy consistent, compliant network infrastructure at scale with zero manual calculation. The standards are written by humans. The execution is handled by machines.