Many people believe that “networks and automation” are a logical combination and that business critical networks are automated in one way or the other. Unfortunately, the opposite is true. While automation capabilities for systems and applications have emerged significantly during the past 10 years, networks are the last bastion when it comes to automation.

I want to start with some statistics. First of all I was shocked to find out that, according to analyst groups such as EMA (Enterprise Management Associates), up to 90% of network errors and outages are caused by configuration errors and that 80% of these errors are caused by manual / human interactions! What this in fact means is that these errors and outages are caused by people making (configuration) changes directly on a device (router, switch or other network device) in the live network, usually an engineer or operator who is working directly on the command line interface (CLI) of the specific device.

Another interesting statistic can be found when comparing systems- versus network automation. A virtual (linux or windows) server for example, can be generated and deployed in minutes (e.g. via an orchestration portal); but it may take days or longer to make this server available on the right network for the right customer, due to the required configuration of ports, vlan’s and ip address allocation. In some cases this is done by different groups of networking people. To make things worse, when looking at implementing a new service across an infrastructure (e.g a layer 2 vpn service), it may takes weeks or sometimes even months to build and deploy this.

Confronted with this all, the Gartner numbers on Total Cost of Ownership for a network became painfully clear to me. Gartner estimates that only 20% of the network’s TCO arises from capital cost for network equipment, 80% boils down to the required training and availability of skilled people, maintenance and missed business opportunities due to long time to market and unavailability of the network.

With this way of working, all network knowledge resides either in the heads of the individual engineers or on the individual devices of the network. When making changes, this often results in a trial and error situation. There is no explicit understanding of the topology and services implemented in the running configurations and as a result a thorough investigation and risk analysis is (or should be) required before making a change. As said, the results are: outages, long time to market and the company’s compliance being at risk. But also, further automation, agility and (self) service capabilities are a no-go in a situation like this. And that’s where I see the true business potential. I will address this in a seperate blog.

Let’s also take a look at the business risks, as there are many other reasons why network automation is becoming more important. Besides the obvious ones as availability and time to market, the human dependency and labour trends are important factors to take into consideration. Gartner indicated earlier this year, that the biggest IT problem for 2012 was the number of skilled people leaving the market. Especially within ‘networking’ where many of the senior engineers are over the age of 50, knowledge management and reducing human dependencies becomes crucial. At the same time complexity continues to increase with developments like BYOD (bring your own device), ipv6, shorter life cycles of services, as well as the need to be more in control in terms of compliancy.

The bottom line is that most networks are not automated and the need to do so is obvious. So the question becomes: how to automate? But before addressing this in more detail, I will share with you, in my next blog, all the arguments I heard in my search ‘why networks can’t be automated’.