Introduction

This high-level, introductory article on network automation is written for decision-makers, managers, and IT team leaders.

It’s 2025—surely everything should be automated by now, right? The industry rhetoric is old enough for a Next Generation reboot, yet we’re still on the explorative side of the journey. Most of the progress so far has focused on Day 1 setups and baseline configs, with a few Day 2 breakthroughs in single-vendor or carefully planned multi-vendor deployments. Vendors, integrators, and customers have poured effort into an automated Valhalla where humans rarely touch the CLI. That vision brings obvious advantages—but also a whole host of not-so-positive trade-offs.

Thanks to the now-ubiquitous spine-leaf architecture, foundational multi-tier data-centre design feels like a solved problem. What remains is the “simple” matter of implementing services and keeping them running. Credit for this stability goes to the POTS-era Clos fabric—a reminder to build on the shoulders of giants and to borrow wisdom from information management, mathematics, and computer science. We’ll unpack many of those lessons in this series and our companion podcast.

What This Series Covers

We’ll explore the core concepts of automation: what it really is, how to shape requirements, and the poorly kept secrets floating in the wild. Consider this an updated field guide from practitioners who’ve lived—and nudged—this journey from both vendor and engineering sides. We’ll help you develop the right mental model, apply it from nuts-and-bolts to end-to-end systems, and work effectively with vendors, consultants, and engineers to turn plans into reality.

We’ll tackle the hurdles that trap most bottom-up efforts—those endless debates of vendor vs. open source, Python vs. Go, YAML vs. GUI, or even “Do you OpenTofu?” (apologies to Steve Rogers and Howard Stark). Without a solid foundation, every future project risks collapsing under its own weight.

Engineering work still matters, but it must follow a plan. The best tools can be misused, overused, or ignored entirely. Define the strategy first; tools follow safely after.

Goals and Use Cases

Start by asking: What problem am I solving? Are you trying to…

• Reduce human error in configuration changes?

• Minimise manual involvement altogether?

• Speed up provisioning and service delivery?

• Enforce security or compliance?

• Automate maintenance tasks like backups or upgrades?

• Manage energy usage across the network?

Your answers—there will be many—drive the approach, technical requirements, and the questions you need to ask, whether the end product is a simple script or a fully orchestrated MSP.

Assessing Capabilities and Current State

Your existing network and team skills are critical. Once a plan forms, create training and labs to explore it technically. Evaluate capabilities on several fronts:

• Multi-vendor environments – Identify device programmability, telemetry, and a common parlance for configuration and operations.

• Existing infrastructure – Consider integrations with IPAM, ticketing, and monitoring tools, and how decisions cross team boundaries.

• Communication – Can your team clearly describe workflows and service lifecycles? Documentation and diagramming aren’t optional.

• Skill sets – Do engineers script? Can they codify workflows in Python, Go, or PowerShell? Are they comfortable with Git?

• Source of truth – Clean, tightly controlled data sources are non-negotiable. If your data is messy, fix this first.

• Repeatable standards - Have you created repeatable design patterns and building blocks? How consistent are your Day 2 activities?

Build vs. Buy

The eternal IT question: build or buy?

• Build – Open-source tools like Ansible, Python, or Terraform provide maximum flexibility and avoid lock-in, but demand heavy development and ongoing maintenance. As features grow, so does the staffing burden.

• Buy – Commercial platforms offer vendor support, training, and quicker deployment, but can be expensive and less customisable.

• Hybrid – Often the most practical route: buy where it makes sense, build what you must, and document tribal knowledge so no single person becomes a bottleneck.

Look for early wins with high impact—observability platforms, network diagramming, or AI-driven root-cause tools can shift mindsets and illuminate dark corners.

Security and Scalability

Automation tools will have privileged access, so security is paramount. Prioritise role-based access control, audit logs, and secure credential management. Ensure temporary access is strictly authorised or scheduled.

Choose tools that scale with network growth. A small-scale success will quickly become unmanageable if the platform can’t keep pace. Build anomaly detection and proactive alerting into your design—no one person can hold the entire network in their head.

Closing Thoughts

This article is just the tip of the iceberg and the first step in our series. If it took longer to read than your macchiato lasted, we hope it was worth every sip.

Work with us on your automation journey and we’ll help you ask the hard questions, shape a winning strategy, and deliver results.

📧 sales@curvium.com
👤 David Gee, Managing Director, Curvium Group Limited
📅 September 2025