Network Automation Beyond OEM Silos : A Program Director’s View on Hybrid Network Cost Risk and Resilience

How I would use cross-domain automation to improve service, productivity and cost control - without automating risk.

ARUNAVA CHAKRAVARTY

Independent Consultant and Strategic Advisor  |  Program and Delivery Advisory  |  PMO and COE Design  |  Program Recovery

The executive view

THE PROBLEM Hybrid services cross multiple OEMs and teams. During an incident, people still reconstruct the service story across consoles and hand-offs.

THE PROGRAM VALUE A cross-domain layer connects evidence, standardises diagnosis and automates repeatable work - improving continuity, capacity, discipline and cost visibility.

THE DECISION Begin with discovery and read-only automation. Prove value and controls in a bounded pilot. Increase authority only when access, rollback, data and ownership are proven.

My guiding principle

Automation is not a tool deployment. It is a controlled change programme. My job is to make the business case measurable, stage the rollout, clarify ownership and make sure the organisation can recover safely when automation is wrong.

1  Why automation matters more in a hybrid network

The strongest use case is not a single-vendor environment where one controller already sees most of the estate. It is a heterogeneous environment where the service path crosses multiple OEMs, technologies and teams.

Keep the specialist tools

The overlay should complement OEM-native platforms, not blindly replace them. Specialist tools retain device-specific depth. The cross-domain layer supplies the shared service context, repeatable workflow and governance that no single OEM can reliably provide across the estate.

Platform first and custom integration where it adds value

I would first assess whether a mature multi-vendor no-code or low-code platform can provide discovery, topology, diagnostics, orchestration and supported connectors. APIs still matter for ITSM, observability, cloud and genuine integration gaps; the discipline is to custom-build only where there is a clear service and business case.

What the programme should deliver

• Faster recovery. Reduce time spent proving domain ownership and increase time acting on a complete evidence set.

• Higher engineering productivity. Move repeatable evidence collection, health checks and known-error diagnostics away from scarce senior engineers.

• More consistent operations. Run the same pre-checks, diagnostics and post-checks across sites, shifts and teams.

• Safer change. Validate before and after changes while retaining rollback and audit evidence.

• Stronger service protection. Protect SLA performance, user productivity and revenue-dependent services.

• Greater vendor flexibility. Avoid tying enterprise workflows completely to one hardware vendor.

  
  

2  Run the programme with clear accountability

Automation works when technical authority and programme accountability are explicit. Technical Leads own design, engineering validation and operational safety. As Program Director, I own scope, sequencing, governance, stakeholder alignment, commercial discipline, programme gates and benefit realisation.

Stage	Technical Leads	Program Director
Discover and baseline	Map service paths, tools, versions, telemetry, connectors and dependencies. Validate data quality.	Define scope, service outcomes, stakeholders and a measurable baseline.
Prioritise	Assess feasibility, platform fit, reversibility and blast radius.	Rank use cases by impact, volume, SLA exposure, complexity and risk.
Pilot	Configure and test workflows; define least privilege, pre/post checks, stop conditions and rollback.	Control scope, schedule and acceptance criteria; compare results with baseline.
Gate	Confirm readiness, supportability and residual technical risk.	Recommend scale, remediate, hold or stop; ensure risk acceptance is owned.
Scale and improve	Standardise patterns and update automations as the estate changes.	Manage rollout waves, suppliers, adoption and benefit realisation.

The accountability rule

Technical Leads decide whether an automation is technically safe and supportable. The Program Director decides whether the programme is ready to proceed based on evidence across value, risk, commercial, people and operational readiness. I should not decide which API or device command to use, but I should ask why custom integration is required, what it costs to maintain, who owns it after go-live and how recovery is assured.

The steering committee scorecard

Programme question	Measure	Value treatment
Are incidents recovering faster?	MTTR, diagnosis time and hand-offs	Risk reduction and avoided loss
Are people doing less repetitive work?	Engineer-hours released, overtime and escalations	Capacity release unless spend falls
Are changes safer?	Change failure, rollback and validation exceptions	Risk reduction
Are we actually saving money?	Licence, supplier effort, overtime and planned spend removed	Cash saving or cost avoidance

The four buckets are all valuable, but they are not interchangeable. In particular, hours released should not be presented as cash unless expenditure actually falls.

3  What can defeat the value

The benefits of automation are familiar. The more useful executive question is what can destroy them when the programme is poorly governed. Four risks deserve continuous attention.

Risk	What can happen	Programme guardrail
Incomplete visibility	Partial topology or unreachable devices can produce incomplete diagnosis and action on the wrong component.	Reconcile inventory, validate coverage, monitor collection status and revert to human-led diagnosis when visibility is incomplete.
Too much authority	An over-privileged account can turn one error or compromise into estate-wide impact.	Use least privilege, vaulting, approval gates, bounded targets and separation of duties.
Unsafe change	A correct script can still be wrong for the current state and widen an outage.	Use pre-checks, canaries, stop conditions, post-checks, tested rollback and manual break-glass.
Over-customisation	Bespoke scripts and point integrations become costly and fragile; the new platform can create another lock-in.	Prefer supported capability, define ownership and review portability, licensing, roadmaps and exit paths.

Due diligence before automation

Before a workflow gains authority, I want six things: a clean baseline, a named process owner, validated and current topology, least-privilege access, tested rollback and an agreed business-value measure. If one is missing, the autonomy level stays lower.

What I would not promise

I would not promise zero-touch operations, a fixed headcount reduction or a universal ROI before the baseline is known. Capacity released is not the same as cash saved, and automation without clean data or safe rollback can make an outage worse.

4  The case for budget approval

I would not seek funding because automation is fashionable or because a supplier promises a particular ROI. I would put a fact-based case before the Executive Sponsor and Steering Committee, showing the operational problem, proposed response, expected value, risks and controls, and the exact phased decision required.

What I would put forward	What the Steering Committee should understand
Current problem and evidence	Incident volumes, diagnosis time, hand-offs, SLA exposure, recurring failures, engineering effort and overlapping tool costs.
Why OEM tools alone are insufficient	The gap exists across the end-to-end service path; specialist depth does not automatically create complete cross-domain context.
What is proposed	A cross-domain observability and automation layer using mature native capability first, with custom integration only for genuine gaps.
Full cost and value model	Show licences, implementation, integration, support and operating costs; separate the four value buckets.
Evidence before scale	Use organisational baselines and bounded-pilot results, including accuracy, time saved, exceptions, adoption and supportability.
Controls and ownership	Show how topology is validated, access is limited, approvals and rollback work, exceptions are handled and human recovery remains available.
Success measures	Agree MTTR, diagnosis time, hand-offs, automation success, change failure, hours released, SLA improvement and finance-validated benefit.
Decision required	Approve discovery and a controlled pilot; release later investment only after viability, control and measurable value are demonstrated.

The decision I would ask the committee to make

Approve a bounded first phase and the governance needed to run it. Do not approve enterprise-wide autonomy upfront. Subsequent funding should be released only when the programme demonstrates technical viability, operational control and measurable business value.

Market direction is context not the business case

The automation trajectory is clear, but forecasts should establish context rather than substitute for evidence. The investment case must still rest on the organisation’s own baseline, controlled pilot, support model and finance-validated value.

NETWORK AUTOMATION <10%  →  30% Gartner forecast that 30% of enterprises would automate more than half of network activities by 2026, from under 10% in mid-2023.

AUTOMATION MATURITY 54%  →  13% In Gartner’s 2026 CEO survey, 54% reported task-specific automation; only 13% expected to remain there by end-2028.

IT INFRASTRUCTURE 70% BY 2029 Gartner predicts that 70% of enterprises will use agentic AI to operate IT infrastructure by 2029.

My bottom line

In a hybrid network, automation is most valuable when it removes operational friction between domains without creating a new layer of risk. The Program Director should put a fact-based case before the Sponsor and Steering Committee, prove the technology and controls in a bounded pilot, use mature platform capability wherever practical, custom-build only where there is a clear value case, and scale only after the evidence says it is safe and worthwhile.

Executive takeaway

Start with visibility. Prove the workflow. Keep authority bounded. Separate capacity from cash. Scale only through evidence-based gates.

AUTOMATION MATURITY

54%  →  13%

In Gartner’s 2026 CEO survey, 54% reported task-specific automation; only 13% expected to remain there by end-2028.NETWORK AUTOMATION

<10%  →  30%

Gartner forecast that 30% of enterprises would automate more than half of network activities by 2026, from under 10% in mid-2023.