Network Automation Needs an Owner Before It Can Scale

Enterprise network automation should not be scaled until it has named owners for every decision and hand-off around a change. A reliable workflow needs more than code that can configure devices: it needs clear authority over the intended state, approval rules, execution, monitoring, rollback and the exceptions that fall outside the standard path.

Without that ownership, a promising pilot turns into a shelf full of playbooks trusted by one engineer, or a platform that can provision a new VLAN (virtual local area network) in minutes but still requires three meetings before it can touch production. The automation hasn’t removed the work. It’s exposed work that was never clearly assigned.

The tool can be sound while the programme is not

There is no shortage of technology for automating network configuration: application programming interfaces (APIs), infrastructure-as-code workflows, orchestration platforms that coordinate multi-step tasks, and network source-of-truth tools. A source of truth is the maintained record of what the network is meant to look like, not an unverified snapshot of whatever happens to be running today.

That distinction is more important than it sounds. NetBox’s documentation explicitly separates intended state from operational state and cautions against blindly importing live data as authoritative. NIST’s configuration-management guidance similarly treats a baseline as a formally reviewed, current specification that supports future changes. Dependable automation therefore starts with an agreed answer to a deceptively basic question: what should this network be? NetBox’s documentation on intended state and NIST’s configuration-change guidance make the point in rather more formal language. (netboxlabs.com)

Tools don’t decide whether a new branch design is acceptable, a firewall exception is justified, an outage window is adequate, or a failed deployment should roll back automatically. Those are operating decisions. Calling the workflow “self-service” doesn’t make them go away.

Ownership must be explicit, not implied

A workable operating model doesn’t require a grand reorganisation or a new committee for every configuration change. It does require named accountability. Where a workflow crosses network engineering, security, service management and a cloud platform team, “the automation team” is not an owner. It’s a convenient way for every group to assume somebody else made the difficult call.

The model should define these responsibilities for every automated service, whether it creates a network segment, updates a load-balancer pool or pushes a standard switch configuration:

• Service owner: accountable for the service outcome, support level, risk acceptance and funding. This person or team decides whether the automation is a supported production capability rather than an interesting engineering project.
• Design authority: defines approved patterns, address plans, routing standards, security boundaries and the conditions under which a request is valid.
• Data owner: maintains the intended-state data and decides how corrections are made when records and devices disagree.
• Change authority: sets the approval rules. Routine, pre-approved changes should be genuinely routine; high-impact or unusual changes shouldn’t be smuggled through the same route because an API happens to exist.
• Automation platform owner: owns the pipeline, integrations, testing approach, credential handling and release process for the automation itself.
• Operations owner: monitors execution, handles failed jobs, communicates service impact and coordinates recovery when the automated path doesn’t complete cleanly.

In a smaller organisation, one team may hold several of those roles. The aim isn’t a perfect RACI chart — the familiar responsible, accountable, consulted and informed matrix — but no gaps between jobs. NIST calls for proposed configuration-controlled changes to be reviewed, approved or rejected with security impacts considered, then implemented, documented and monitored. Software sending the commands doesn’t change that sequence. (nvlpubs.nist.gov)

The dangerous gap is exception handling

It should state which services are supported, who owns each decision point, what data is authoritative, how requests are validated, when approval is required, how success is observed and what happens after partial failure.

Happy-path automation gets the demonstrations. Production ownership shows up in the request that doesn’t fit: an acquired site with unfamiliar addressing, a legacy switch without the required API, a supplier circuit arriving late, or an incident that needs a change outside the normal window.

If the answer is “an engineer will sort it manually”, the programme needs another answer: who records that intervention, who reconciles it with intended state, and who decides whether the exception becomes a supported pattern or remains a one-off risk? Without that discipline, manual changes accumulate alongside automated ones. Eventually the data isn’t trusted, the automation is paused “temporarily”, and the old ticket-and-CLI (command-line interface) process quietly takes over again.

This isn’t needless bureaucracy. CISA describes configuration management as a formal process for documenting and managing changes, monitoring deviation, and considering orchestration, change control and reversion to a known-good state. A network automation programme needs the same practical loop: plan, validate, deploy, observe, reconcile. (cisa.gov)

Legacy infrastructure needs a coexistence plan

Few enterprises get to start with a clean, uniform estate. The usual reality is a mixture of modern platforms, old campus kit, appliances with partial APIs, outsourced connectivity and a few critical devices that everyone agrees shouldn’t be touched casually.

The sensible response isn’t to postpone automation until every last device is modernised. Be honest about capability tiers instead. Automate standard, repeatable services first; use read-only discovery and configuration backup where safe write automation isn’t yet realistic; retain controlled manual processes for genuinely awkward equipment. Most importantly, make each tier visible. A workflow that works across 70 per cent of the estate is useful. A workflow presented as universal while carrying silent exclusions is operationally dangerous.

There should also be a defined route back from emergency work. During an incident, restoring service is rightly more important than preserving a pristine workflow. Afterwards, though, the live change must be reviewed and either reflected in the source of truth or deliberately reversed. Otherwise “emergency” becomes another route around the model.

Signs that nobody really owns it

Most organisations don’t announce that their enterprise network automation programme lacks ownership. The signs are usually more mundane:

• Only the original author can explain or safely run a production workflow.
• The source-of-truth data is treated as useful reference material rather than the approved basis for change.
• Automation failures create tickets, but no team has an agreed service target for fixing the platform or reconciling the affected configuration.
• Security, network and service-management teams each believe another group approves automated changes.
• Manual fixes are common, but nobody measures how often they occur or feeds them back into designs and templates.
• Success is reported as the number of scripts written rather than the number of services that can be changed reliably, supportably and repeatedly.

These aren’t merely delivery annoyances. They make it harder to know which configuration is trustworthy and who is empowered to act during a fault. That is why configuration-management guidance focuses on controlled baselines, approval, documentation and monitoring rather than treating automation as a substitute for control. (nvlpubs.nist.gov)

What leaders should establish before scaling

Before expanding from a limited use case to an enterprise-wide platform, leaders should insist on a short, testable operating contract. It should state which services are supported, who owns each decision point, what data is authoritative, how requests are validated, when approval is required, how success is observed and what happens after partial failure.

Set an operational measure that people can’t game, too. “Jobs completed” isn’t enough. Better measures include the proportion of standard changes completed without manual intervention, failed changes reconciled within an agreed period, configuration drift — differences between intended and live state — detected before an incident, and exceptions turned into documented patterns or retired. The objective isn’t more automation activity. It’s more dependable network change.

Automated infrastructure control needs clear human authority, evidence and recovery paths. Those same concerns sit at the heart of AI agents in the enterprise, where identity and access determine what automated action is permitted. They cannot be bolted on afterwards.

A reliable programme is a service, not a repository

Enterprise network automation becomes dependable when it is run as an operational service with customers, boundaries, support expectations and accountable owners. Scripts, templates and APIs are essential ingredients, but they aren’t the operating model.

Vendors often glide past that point when they promise faster change and fewer errors. Those outcomes are plausible, especially for repetitive, well-understood work, but they aren’t automatic. The real achievement is a system in which routine changes are faster because the organisation has agreed what safe routine looks like — and knows exactly what to do when reality refuses to comply.