Hi Graham, The talk was giving in context of motivating people to start with network automation and help them go from 'no automation' to a step further 'some automation'.
On Wed, Jun 14, 2017 at 07:50:05PM +0000, Graham Johnston wrote: > Would you be able to provide any further insight into your Don’t #5 – > “Don’t agree to change management. I think the development team of the network automation software should define their own process around change management. If you want to use kanban? great! if you want to use simple fifo model applied to issues filed on your private github project? great! My point was: don't let someone from higher up dictate how, and when you do software releases. Another aspect is that you most likely will have proceses that should run without any human intervention: such as the nightly update for all EBGP prefix-filters. You don't want to end up in a situation where a computer generates those configs and has to hand them over to a human for some additional checks and subsequently pushing it out to the network. Imagine having the computer print out your automatically generated configs, a human pick them up, review them, and type them back into a computer for the changes to take effect! That would be terrible. > Managers are rarely engineers and should not be making technical > decisions. (nor should sales)“. That was a simple point: ideally a manager enables you to do your work, and trusts you to do the work. If you have a manager who opinionatedly argues with you on tabs vs spaces or how to push a configuration to a device, you might find that you don't have enough freedom of movement to succesfully bootstrap the automation project. In other words: don't roll over and blindly accept what other (inexperienced) folks within the organisation tell you, try to find your own path. However, do make sure you steal the good ideas from the sysadmins: they often are ahead of netops in terms of automation and understanding idempotency. Kind regards, Job