Automation fails for a reason that has nothing to do with Python: the thing being automated has no model. A CLI is designed for a human reading and typing, so its output is prose, its commands are order- dependent, and its error messages are sentences.
A data model is the opposite: typed, hierarchical, and validated before it is applied.
Three layers people confuse
| Layer | What it is | Example |
|---|---|---|
| Data model | The schema: what exists and what is valid | YANG module for interfaces |
| Encoding | How it is written on the wire | XML, JSON |
| Protocol | How it is transported | NETCONF, RESTCONF |
You can change the encoding without changing the model, and the protocol without changing either. This is why "we use REST" is not an automation strategy.
What a model buys you
- Validation before change. A wrong type or a missing leaf fails at the schema, not at 02:00.
- Idempotence. "Ensure VLAN 104 exists" is expressible; "type these commands" is not.
- Diffing. Two models can be compared; two CLI transcripts cannot.
- Multi-vendor abstraction. OpenConfig models the same concepts across vendors.
YANG in one page
YANG describes a tree: containers, lists, leaves, types, and constraints.
container interfaces {
list interface {
key "name";
leaf name { type string; }
leaf enabled { type boolean; default true; }
leaf mtu { type uint16; default 1500; }
leaf description { type string; }
}
}
That schema says an interface has a name, an enabled flag, an MTU, and a description. A device that implements it can be configured by anything that speaks a protocol carrying this model.
Intent versus configuration
| Configuration | Intent |
|---|---|
| "Set port 5 to VLAN 104" | "This port serves student devices" |
| "Add route 10.50.0.0/16" | "The new campus is reachable" |
| "Set channel 6 on AP-14" | "This AP is in the north wing plan" |
Models sit between the two: intent is expressed as data, and the model validates it. Most districts stop at "configuration as data," which is already a large improvement over CLI scripts.
Not every device speaks a model
Older switches, most access points, and nearly all building-control gear expose a web UI or CLI only. Automation there means scraping, which is fragile. Model-first thinking tells you where automation will pay off and where it will become a maintenance burden.
Worked example: VLANs as data
vlans:
- id: 104
name: student
subnet: 10.40.40.0/21
- id: 106
name: staff
subnet: 10.40.60.0/22
That file is a model in the practical sense: it can be validated (unique IDs, subnets inside the site block, names matching the scheme), rendered into device configuration, and diffed between versions.
The schema is the value. A YAML file with no validation is just a config file with extra steps.
What breaks in production
- Scraping CLI output and calling it automation, which breaks on the next firmware.
- No schema, so a typo becomes an outage instead of a validation error.
- Vendor models treated as portable, when each vendor's tree differs.
- Intent never expressed, so the automation encodes "how" and cannot adapt.
- Automating the wrong thing first: a rarely changed device instead of a repeated one.
Next
The model exists; something has to carry it. Continue with NETCONF, RESTCONF, and YANG.