In my first blog, I spoke about myth number 1, i.e. that network automation is commonly used and implemented for managing our networking infrastructures. Unfortunately, the opposite is true and after realizing this, my next step was to speak to the specialists in the field: the network engineers, and ask their opinion on this topic.
In general, the first response I get when talking about network automation is, “you mean monitoring tools?” Apparently, this is the first thing that comes to mind. And in itself this is logical considering the fact that during the last 15 years, network management has been primarily about monitoring events and faults.
When I say to them that I mean automating the process of making configuration changes, the second misunderstanding arises, namely on the topic of configuration management. Many organisations, after having implemented fault management (the”f” in the “fcaps” model, a commonly used framework for network management), consider configuration management (the “c”) as the process of backing up configurations from existing networks. In itself this is good for verification and compliance purposes, but in essence always a reactive process. This has nothing to do with automating change management!
Once this is clear, only about 10% from the companies I have spoken to have gone beyond this point. In most cases via in house scripts made by smart engineers, usually to automate a specific repeatable change task. Some have taken a more structural approach by implementing an actual platform for provisioning. And although this is a good thing, provisioning is only the first step in network automation. It typically focuses on activation and roll out or new services using a ‘fire and forget’ strategy, whereby a configuration is pushed to the device. Administration afterwards is not controlled from that point forward. As a result, the information resides on the nodes and not in a central leading place / database that is used for additional changes in the future. And as the process of making additional changes afterwards is still manual, it remains unclear what the running config is.
The true challenge is to automate changes throughout the lifecycle of the network. Speaking to companies who have mastered this, the key point is to be in full control of the data and parameters that make up your network (ip numbers, vlan numbering, port blueprints, etc..) and at the same time master the process of config generating and making changes in the network. This is where the discussion with many engineers start. Mastering network parameters implies standardization (on how to use your ip space for example, vlan numbering, blueprints for ports and standard designs for expansions) and controlling the change process implies a uniform way of working between engineers and operations.
I have been in heated discussions on these topics as most people don’t want to change their current way of working and many believe it is impossible to apply standards throughout their networks. Interestingly though, the ones who have been successful disagree. They know that implementing standardization can be done in many ways, while leaving enough room for ‘specials’ if needed. I’ll touch on this in one of my next blogs.
The essence is that network automation is very feasible when organisations are open to streamline processes between design, engineering and operations and decide for a top down approach on change management. My next blog will be fully dedicated to this topic.
