The network automation readiness checklist

Automation programmes rarely fail because the automation was bad. They fail because the network underneath it could not support automation, and nobody checked first. This is the assessment we run at the start of an engagement, written out so you can run it yourself.

Score each item honestly as yes, partly or no. The pattern of answers matters more than the total.

1. Source of truth

• Is there one system that is authoritative for network inventory, and does everyone agree which one it is?
• Is IP address management structured and queryable, or does it live in a spreadsheet?
• Can you retrieve device data programmatically over an API?
• Is intended configuration state recorded anywhere, separately from running configuration?
• When someone racks a device, is there a defined step that updates the record?

If you answered no to the first question, stop here. Everything downstream inherits this problem, and no amount of tooling above it compensates.

2. Configuration management

• Are configurations version-controlled, with history you can diff?
• Are configurations generated from templates rather than edited by hand?
• Do you know, right now, how far running state has drifted from intent?
• Is there a tested rollback path for a config change, or only an assumed one?
• Does a change produce a structured record — what changed, where, when, by whom?

That last item is easy to overlook and disproportionately valuable. Change correlation is the fastest route to a root cause, and it requires a change log a machine can read.

3. Provisioning

• How long does a new site take from delivery to production, and how much of that is configuration?
• Would two engineers building the same site produce the same result?
• Is circuit provisioning tracked in the same system as everything else?
• Does a newly provisioned device get validated against intent before it carries traffic?
• Can you rebuild a failed device from record without archaeology?

4. Observability

• Are metrics, logs and flow data labelled consistently enough to join on device and site?
• Do you have streaming telemetry, or only polled snapshots?
• What proportion of alerts result in action? If it is under a quarter, you have alert fatigue.
• Do you retain enough history to establish a baseline for normal?
• During an incident, how many separate tools does an engineer open?

The last question is the useful one. Every tool boundary is a place where correlation becomes manual, and manual correlation at two in the morning is where the hours go.

5. Agent readiness

• Could a system query intended state and running state and compute the difference?
• Are your runbooks written down, or held by a handful of experienced engineers?
• Is there an approval mechanism a machine could route a proposed change through?
• Do you have policy on what an automated system may change, and under what limits?
• Is there an audit trail that would satisfy a post-incident review?

Reading your results

Mostly no in section 1: start there and nowhere else. A source of truth is the only prerequisite that has no workaround.

Strong in 1 and 2, weak in 4: you can automate change safely but you cannot yet diagnose well. This is the most common profile we see, and observability work has the highest marginal return.

Strong across 1 to 4, weak in 5: you are ready for an agent, and the remaining work is policy and process rather than infrastructure. This is usually a matter of weeks.

Mostly yes throughout: you are in a small minority. The question worth asking is which class of incident still consumes the most engineer-hours, and whether it is diagnosis or remediation.

What we do with this

Our 30-minute readiness consultation works through this checklist with you and produces a written view of where you stand, which gaps matter most for your environment, and what the first three months would sensibly contain. No discovery scripts, and nothing installed.