One aspect of network operations and management (O&M) that I am passionate about is automation (to be accurate, Orchestration; where different tools integrate and work together to deliver a common outcome; but will stick with the word “automation” here). There are many reasons I can catalog for this; but the most important for me is that it removes subjectivity from Network O&M. This is good for Day 1+ operations because network devices operate in a deterministic manner once configured. Any variability or subjectivity we observe is not due to the devices having a mind of their own; it is mostly due to we not fully appreciating how various constructs interoperate either during the manufacturing of the device or configuration of devices. Simply, devices just do what they are told. Even when there are bugs, it is the network device operating in the way it was coded; hence we fix it with another code. This is the reason subjectivity in Day 1+ operations is not ideal. Automation helps us deal with this because we are able to curate the approach to take in achieving an outcome, apply guardrails and validate same, before implementing. The outcome is that all engineers have an agreed objective way of operating or managing the network. This protects us all against subjective errors.
But the thing is automation does not fix broken processes and/or non-standard network setups; automating a bad process makes it worse.
And the flip side is that , deciding against, or holding-off automation makes it harder to start automation, to the point where it is riskier to automate, than not to.
So how do we address it? – A balancing act.
1. Classify the “broken things” that need fixing into 4 quadrants; those you have control over, those you don’t, low-hanging fruits, and high-hanging fruits.
2. Then start your automation journey while working at unblocking low-hanging fruits that are in your control, with a strategic plan for the other combinations.
What fits where will differ from organization to organization. What holds true in most cases for all organizations is that, inventorying your network artifacts into a single source is an area that would be in our control, and one that can be achieved with relatively less lifting. Moreover, this is a key dependency for your other automation activities; so it is a good place to start. Same with centralizing our automation functions. Standardizing your network is a continuous effort that you should plan for and work at; like device software standardization, configuration standardization, physical component standards etc. Then iterate over this as you continuously improve. It never ends.
In all this, alignment with key stakeholders is key. Automation is not an event, it is a journey. So take the first step now …