Automation has been part of enterprise networking ambitions for the better part of two decades. However, despite nearly 20 years of desire, the vast majority of enterprise networking is still driven manually. At some point, if the industry is going to take a collective step forward, it has to develop an opinion on what is holding automation back, and then take fundamental steps forward to ensure that those obstacles are overcome. But where do enterprises start? Mike Bushong, Vice President, Enterprise and Cloud Marketing, Juniper Networks explains.
The common refrain from management on both the user and vendor sides is that automation is the key to reduced operational expense and greater agility. But in framing the discussion around these points, leadership has been simultaneously misconstruing the primary goal of automation while dissuading and distracting teams from taking meaningful action.
Companies that view IT primarily as a cost centre will likely find that there is never a good time to automate. Directing resources away from higher-priority projects to what is viewed as better hygiene is a difficult case to make in companies concerned mostly with alleviating OpEx pressures. So, where the network is not a core part of the business, it’s unlikely to see the requisite investments to really make progress on an ambitious automation agenda.
Perhaps more insidious, though, is the fact that the very people required to embrace automation in these companies are the ones who fear they will lose their jobs as a result. While it is unlikely that automation leads directly to job loss, leaders are unintentionally poisoning the workforce, which will create cultural misalignment certain to dampen progress.
In today’s enterprise networks, most enterprises are capable of scripting their changes and building basic automation hooks to move faster. The reason they don’t? Because moving faster when making changes to something that has been historically fragile is dangerous.
Nouns vs. verbs
When it comes to network automation, the most basic question that most enterprises struggle with is: what do you want to automate?
Almost invariably, the first response is: the network. The challenge here is a matter of nouns and verbs. At a foundational level, enterprises cannot automate a network any more than they can automate a table. Automation is about verbs—the act of doing something on a network. And without a solid understanding of what the verbs are, there is no good place to start.
Companies interested in making headway in the automation arena need to become masters of workflow identification. If you ask an individual to identify workflows, they will likely default to workflows over which they have full control. That is to say that the workflows that most people identify are the ones over which they have full, end-to-end control. The problem here is that these are not the highest-value automation targets.
Automation is not about removing keystrokes. The elapsed time to complete a workflow is rarely dominated by typing time. Rather, time accrues at the boundaries. Those boundaries can be between people, as when collaborating on a task. They can be between systems, particularly when output from one system is used as an input into another. Or they can be between organizations, such as when teams must coordinate on a project.
Automation needs architects, too
Finally, if enterprises want to really reap the rewards of a strong automation practice, they need to think about automation as a starting requirement rather than an operational bolt-on. For far too many enterprises, automation is something that happens in the weeks and months and even years that follow a major deployment.
As a closing thought, reliability is built on the back of uniformity, which means that automation must drive uniformity. Networking is notoriously bespoke, as is the case with fragile things. When it’s not absolutely critical, don’t change anything. But this leads to operational diversity—the enemy of automation.