Network Engineering Should Be a Standard, Not an Art

In today’s business landscape, the network is more critical than ever. Organizations are investing in automation and orchestration to accelerate network operations and power the innovation and agility they need to get ahead.

Automation isn’t just about speed, though. Equally important (or even more, in some industries) is reducing incidents and eliminating network downtime. Manual network management has always had some risk of human error — even when networks were smaller, there was a certain amount of risk baked in. But this risk becomes far greater in today’s evolving networks, distributed across multiple clouds and network domains and comprised of a wide variety of vendor and in-house systems.

Automation and orchestration can introduce greater standardization to network management, allowing teams to avoid incidents and keep their distributed network running. But what does standardization mean in an environment that’s so, well, non-standard? When different network domains require different toolchains, and different teams make their own decisions around automation?

For one of our customers, Fiserv, standardization is the golden rule for their automation efforts. Fiserv’s Director of Architecture and Automation, Michael Wynston, put it like this:

“Network engineering is not an art. It should be a standard.”

He’s 100% right.

At the same time, he emphasizes the need for different teams to use their own best-fit tooling to automate within a given domain. You can read about Fiserv’s full automation journey here, but for the purposes of this blog, we’re going to stick to the standardization subject.

In partnership with Itential, Fiserv landed on an operational model that is developing and taking hold across many organizations in multiple industries: a federated capacity to automate and orchestrate the network. Each domain automation team will have the ability to automate in the way they choose, whether that’s a fully DIY strategy with code and open source tools, a reliance on vendor-provided controllers for a set of devices, or a hybrid strategy. But above that, at the orchestration and exposure layers, there is consistency in terms of how the organization operates automation. How automation is delivered, how it’s consumed, how it’s shared, etc. People might have different templates and different ways of working, but, for Fiserv and others, the way tickets are managed, the way automation and orchestration is delivered for self-service, the way testing is done, and other operational components are all standard and consistent.

The goal is to allow teams to take advantage of tooling that’s built for their own needs without requiring bespoke solutions and custom development to orchestrate multi-domain processes and deliver them to consumers (application developers, network operators, security personnel, etc.).

We can also look to the domain level itself for another form of standardization, one which is inherent to automation. When a process is done manually, even if there’s a routine set of steps that’s known within the team, you can think of it as a bespoke process each time—there’s always a chance that some step will be performed slightly differently, whether by accident or by design. When SMEs are able to build automation assets that turn tribal knowledge into a repeatable, usable “thing,” and when those assets can be securely shared with anyone who needs to use them, the entire organization benefits: network operations happen faster, yes, but more crucially, we eliminate the possibility for human error within a given process. Then, it follows that the more automation assets an organization produces and can leverage, the more they reduce the risk of human error, and the more reliable their network becomes.

As Michael said in a Packet Pushers episode detailing Fiserv’s automation journey, automation is about “making sure the engineer is doing things in a way that doesn’t introduce any incidents. That doesn’t introduce any creativity.”

It’s pretty straightforward, but let’s quickly summarize why a standards-based approach to network automation and orchestration is so important:

Trust: Trust in automation, trust between teams, trust in data and sources of truth — trust is one of the most consistent barriers to automation adoption we see within network teams. Standards build trust — the reason the network team is trusted to handle a given manual process is because they’re seen to have a standardized procedure for said process. The right approach to automation and orchestration will allow all of these procedures to be automated, allowing teams to trust in automated activities coming out of any other domain, and allowing orchestration to leverage any automation from any domain with confidence.

Participation: The more engineers and operators who can participate in automation (building it, executing it, or both), the better. When something is standardized to fit within a larger operational model, then even someone without the requisite skillset to build or understand a given automation asset can still leverage that asset to achieve a desired outcome.

Reliability: The big one. Network downtime can cost millions. Earlier, I mentioned Fiserv, one of the world’s largest FinTechs. They handle trillions of dollars in transactions a year, so you can imagine the impact of even half an hour of network downtime. But even outside of large-scale financial services, network downtime is becoming more and more costly, and businesses are turning to automation to improve the reliability of their networks.

Network Automation

Standardizing automation doesn’t mean forcing everyone to use the same tools. It means creating a consistent framework for how engineers can securely deliver automation assets across the organization and how automation is consumed. Itential’s automation capabilities allow domain teams to use any tooling they choose, providing a centralized high-code execution environment for Python scripts, Ansible Playbooks, OpenTofu plans, etc. — across all network domains.

These capabilities allow automation engineers to focus on building automations — without wasting time managing them.

Network Orchestration

Itential’s workflow orchestration capabilities integrate with any network automations along with IT and network systems to facilitate the creation and delivery of multi-domain services across hybrid infrastructure. Teams can coordinate any number of automated processes to drive efficiency across the network by turning multi-step processes into end-to-end outcomes that can be delivered as self-serve products for end users to consume.

This is the kind of standardization that really powers complex, distributed networks — you’re standardizing how things are operated, delivered, and utilized so that individuals and domain teams can use their own non-standard ways of working while still being part of the overall strategy.

To learn more about Itential’s orchestration capabilities, click here. And to hear more about standardization and the network automation journey overall at Fiserv, check out this recent Packet Pushers episode with Michael Wynston.