Most Network Automation publications tend to focus on the technology, how to code, build useful pipelines, and this week’s tool of fashion. But isn’t that a very one-sided view of the topic? I mean after all, people are what make automation happen and drive those projects forward. Thankfully Skynet is too far away to autonomously build automation frameworks and the ‘Self-driving Network’ never made it from marketing to the real world.
Typical Concerns
Depending on who started the automation initiative, namely management, dedicated team member, or external consultancy, you might hear things like this.
- “Oh, but our network is too old, unique, small, large or complex.”
- “My job role says Network Engineer, not Software Developer.”
- “We tried it before and didn’t succeed, so just go away.”
- “Automation is such an overwhelming huge topic, where should I even start ?”
- “We’re not Google, we don’t need any of this.”
Or you might not hear any of those, which is even worse because then you are facing hidden concerns. In any case, it is important to understand what might be the reasons behind those reactions.
- Fear of change / the unknown
- Fear to get automated out of the job
- Hesitant to learn something new
- Fear of losing the value of acquired knowledge
- Don’t see the use case
Also, presumably each of us will know a colleague who is completely satisfied with being a ‘human API’: Ticket in, click-click-hack-click-clack, Ticket out.
Typical Justification
At this point, most managers or experienced automation experts default to recite all the good reasons. Like reliability, consistency, repeatability and yes, we need to do more with less and way faster than today. Unfortunately, all these good (business) arguments are unsuitable to dispel human concerns.
I once made the mistake of proposing configuration backups via Git out of the blue. Just to hear: “Why should we store our configs in this new GitLab tool, we already have a backup solution in place?”. Totally missing the point about embedded versioning and the added value of GitHub/Lab as a collaboration tool. Of course I had the vision of Infrastructure as Code and GitLab as a central repository and only tried to sell config backup as a first simple use case. Lesson learned: Paint the big picture first.
On the other side, I experienced and heard enough stories about higher management fell in love with some vendor PowerPoint and let the following message trickle down the hierarchies: “We bought this outstanding automation framework from vendor X, now go, automate all the things.” – a wrong approach as well, and the first error happened way before the first line of code.
So let’s face it: It’s not enough to personally recognize the meaning of Automation or be a killer programmer, the idea has to be actively promoted to convince the rest of the team or even the whole organization.
A Graceful Start
These are just proposals, every company is different, so please take what you need and choose a path according to your needs.
Create a Common Understanding
Someone has to answer, or better moderate a process to answer, at least the following questions.
- Why do we need Network Automation?
Hint: Some of the arguments above. - What are the (first) goals that should be achieved in our company?
- What are the expected advantages and disadvantages of the process?
- How will work change in the future?
It’s all About Communication
After that initial kickoff phase, talk. Talk to everyone who doesn’t escape fast enough, chances are small to overcommunicate this topic. Little Meetups, Demo sessions, or even better some form of Hackathon with the goal to automate a little task are a great way to spread the word.
Acceptance Is Key
Early success with easy tasks is important to see the value of Automation and it’s potential to make life easier. Pick one little but tedious daily task and automate it for your team. It has not necessarily to be a config management function. Even read-only information gathering for the purpose of Day-2 operations or automatic documentation are valid first use cases.
Build a Long Term Strategy
It’s smart to focus on ticket based processes first. The goal is to reduce human interaction by exposing a service via an API or a self-service web portal (to other teams). Aim at fully orchestrated services at an advanced stage of the journey, silo-busting style.
The Management Plane
An automation initiative needs time and resources and thus support from the leadership. It should not be expected that all employees acquire automation skills in addition to current tasks or possibly even in their free time. Some tasks might even take longer than usual at first, because there is upskilling, troubleshooting, and documenting involved. The whole process should be viewed more as a medium rather than short term effort. Also, there is initially hidden value in repatriating operational knowledge from vendor support to your organization.
One Person, or even better a little team has to own and drive the process, people with the right attitude, people that buy-in.
Provide a budget for training and licenses. Questions like “Why does a Network Engineer need a GitLab license?” must never happen.
Understand and regularly confirm that nobody will be replaced by an Ansible playbook. The main advantages of highly automated and orchestrated infrastructure are faster delivery times of a growing number of services and reliability due to new validation options – not the possibility to cut staff. The time saving that will certainly occur is required to maintain and further develop the automation stack.
Key Takeaway
There is more to Network Automation than just the tools. Despite all the enthusiasm for the new possibilities, the human factor in the equation should not be forgotten and there has to be a certain culture to have people aboard. Because all the scars, I mean, the network domain expertise is what ultimately sets us apart from a trained software developer and finally makes the difference.
Or based on Peter Duckers famous statement: “Culture eats Automation for breakfast.”
Headerimage by freepngimg.com
NWMichl Blog 