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?
Start with why
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.
But what about agility? Surely, automation is about making things go faster. Except that speed is not the issue.
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.
If enterprises want to be speedy but cannot because of fear of breaking things, then automation must fundamentally address the reliability issue. If the network becomes more reliable, then enterprises will be able to move more quickly, which drives both cost and agility. It’s not that cost and agility are not downstream benefits, but they only come as a result of making the network more reliable.
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.
The verbs to focus on are workflows. In a discipline defined primarily by configuration syntax, there is a surprising lack of emphasis on workflows. Workflows are sets of tasks that are strung together to meet some meaningful business objective. In the absence of knowing what the workflows are, it’s difficult for operations teams to identify the likely candidates for automation.
Companies interested in making headway in the automation arena need to become masters of workflow identification.
Not all workflows are created equal
If you ask an individual to identify workflows, she will likely default to workflows over which she has 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.
The implication here is that there is rarely a single individual who spans these boundaries, which means that enterprises need to expand their working teams if they want to deliver transformational value.
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.
Automation requires a heavy emphasis on things like monitoring and analytics, which means building these as requirements into device selection. It relies on data distribution so that information can be shared across boundaries, which means having a strategy for connecting things and people beyond just process. And it requires an architectural approach that promotes explicitly the reuse of automation building blocks. Only with heavy reuse can the primary objective of reliability be achieved.
One more thing: the cloud
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.
So as enterprises consider their moves to the cloud, they should be expressly thinking about how to drive workflow uniformity despite the differences in infrastructure. Doing this will ensure that automation is not just relevant in on-premises solutions but also in the future architectures surely to include some measure of cloud.
Discussion about this post