Network Orchestration

The Daunting Reality of Network Change Management Requests

Peter Sprygada

Vice President, Product Management ‐ Itential

The Daunting Reality of Network Change Management Requests
Share this:
Posted on April 11, 2022

It’s no secret that network engineers are stuck spending their days working through never-ending backlogs of network change requests across multiple network technologies including CLI devices, API-enabled controllers, and public cloud networking elements as well as ensuring adjacent tools are updated to reflect each change. With the convergence of both network automation and cloud automation, how do these two worlds come together so enterprises can address the full end-to-end automation needs to reduce that backlog?

Recently, I presented at Networking Field Day 27 to tackle this topic and help network teams better understand how they start to reduce, and eventually eliminate, their backlog of change requests by delivering network automation at scale.


What Enterprises are Facing Today

Before we dive into what it takes to scale automation, it’s important to understand why it’s been so difficult for teams to do. Long gone are the days where a network simply consisted of routers and switches, where all you had to do was log in and made changes to them. That no longer is today’s heterogenous, hybrid network infrastructure that you find deployed in enterprise. With this shift, there is now the need to operationalize your entire network through automation – WiFi devices, SASE devices, SD-WAN, cloud infrastructure, etc. All of these are starting to come into the fold and are being saddled on NetOps teams to figure out how to start making sense of all of this as they’re all paramount to building infrastructure in support of building companies’ application.

The struggle teams are facing in this new world is how to deal with this problem. Engineers already have their hands full taking a predominantly CLI-driven device with no API on it and trying to automate that through scripts and now they must figure out to automate infrastructure that is comprised of both API and CLI devices. This raises a big question – how do you bring all of this together into one single workflow, and in a way that makes it accessible to your entire organization?

We all have ideas how about automation should or could work, but we can all agree that if automation isn’t made accessible for everyone, from the most senior to the most junior engineers, automation projects are doomed to fail — at least at scale.


The Daunting Reality of Network Change Management Requests

The reason backlogs never end is because the current processes teams are using to complete network changes aren’t scalable. The current approach is more like a game of telephone – someone starts with a message and keeps repeating until we get to the end, and by the time the message reaches the end, it’s changed and what’s getting built isn’t necessarily what was originally intended.

First, it may be initiated by Slack, an email, ITSM system such as ServiceNow, or even in some instances, a phone call. This then sets in motion a whole series of events and this is where network automation HAS to begin. Currently, over the series of steps, different individuals across the organization start to spin up tasks. Think of it as a relay race – one task being passed from one to the next to get to the finish line. They have to perform a series of checks, data analysis, and data collection. All of this has to be done to even get to the deployment itself. Once the deployment is complete, there’s a whole other set of tasks on the backside. Individuals have to check and make sure the network is still normalized and still running, have to update backend systems.

This is what enterprises are dealing with today in their network change requests process — passing things from one to another, making subtle changes along the way. The only way to solve this huge problem is by extending automation from ticket creation to ticket closure and eliminating the game of telephone.


How Itential Operationalizes Network Automation to Deliver at Scale

It all starts with the cyclical nature of network automation. It always starts with design. Itential provides a way to virtualize your white board concept of automation design inside our product so each team can bring their own piece to the canvas. This allows teams to build automations that focus on the full end-to-end process of a network change encompassing the design of the change, the configuration that needs to be made, the validation check to ensure the change is correct and that ability remediate it the change, if needed.

Itential provides an entire suite of products focused on providing today’s network teams the ability to automate from ticket creation to ticket closure. We do this by focusing on bringing API capabilities to the prevailing frameworks and tooling in place today that are designed to deliver automation. We also provide a Pre-Built Collection of Integrations, Automations, and Transformations so your team doesn’t have to start building from scratch.

You can watch my full session below or check out the full lineup from Networking Field Day 27 to explore this topic deeper.

If you’re ready to give it a try for yourself, click here to create your free account of Itential Cloud and get started automating in minutes.

Peter Sprygada

Vice President, Product Management ‐ Itential

Peter Sprygada serves as the Vice President, Product Management at Itential after serving as the Chief Technology Officer at Pureport where he was responsible for their multi-cloud network as a service interconnect platform. Prior to Pureport, Sprygada was a Distinguished Engineer for Red Hat, where he played the role of Chief Architect for the Ansible Automation Platform. Sprygada also held senior technical and leadership positions at Arista and Cisco, as well as several networking startups.

More from Peter Sprygada