Planning network automation: benefits, risks, skills and a staged roadmap

Why automate, and what can go wrong

Manual work by the command line is slow and inconsistent. Two engineers configure the same feature in slightly different ways, a typing mistake takes down a site, and an urgent change waits until someone is free. Automation addresses this.

The common barriers are rarely technical. They are lack of time to learn, fear that automation will replace jobs, and no agreed standard configuration to automate in the first place.

Automation, orchestration and programmability

These words are often used as if they meant the same thing. They don't.

• Programmability is a property of a device: it offers interfaces such as NETCONF, RESTCONF or a REST API that software can use.
• Automation is using software to carry out a task without manual steps, such as backing up every switch or adding a VLAN.
• Orchestration co-ordinates many automated tasks across different systems into one workflow, for example creating a new branch: firewall rules, SD-WAN site, DNS records, IP addresses and monitoring, in the right order with rollback if a step fails.

Programmable devices make automation easier; automation is the building block that orchestration strings together.

A staged roadmap

1. Read-only first. Inventory reports, configuration backups and compliance checks can't break anything and quickly show value.
2. Standardise. Agree a standard configuration per device role and move device data into a source of truth.
3. Automate low-risk changes. Port descriptions, VLAN assignments and user accounts, with check or dry-run modes.
4. Add pipelines. Store everything in Git; changes are peer-reviewed, tested in a lab and deployed by the pipeline.
5. Close the loop. Monitoring events trigger automated, pre-approved fixes, for example shutting a port that starts a broadcast storm. See AIOps and autonomous networks for where this leads.

Tip: choose your first project from your team's most hated repetitive task. Quick, visible wins make it far easier to get time and support for the next stage.

Measuring success

Pick a few simple measures before you start, and record a baseline:

• Average time to complete common requests, such as a new VLAN or a firewall rule.
• Number of changes that caused an incident (the change failure rate).
• Share of devices that match their standard configuration.
• Hours a month spent on repetitive tasks.

Report these every quarter. Numbers persuade managers far better than "it feels faster".

Real-world example: a small team starts small

A fictional council's three-person network team supported 300 switches across libraries, depots and offices. Nobody had time for a big automation project, so they began with a nightly script that backed up every configuration to Git and emailed a list of devices that had changed. Within a month it caught an unauthorised change at a depot. Next they agreed a standard library switch profile and wrote a compliance report showing 60 switches that differed from it. Six months later new library sites were built from templates, and request times for VLAN changes fell from three days to under an hour.