Where Does Automation Fit into Enterprise IT?

One of my readers coming from system development area asked a fundamental question about the role of automation in enterprise IT (somewhat paraphrased):

[In system development] we automate typical tasks from the pre-defined task repository, so I would like to understand broader context as the automation (I guess) is just a part of the change we want to do in the system. Someone needs to decide what to do, someone needs to accept the change and finally the automation is used.

Of course he’s absolutely right.

As I explained numerous times (for example, in Network Automation 101 webinar), you can automate only well-defined tasks. If you can’t define a task as a series of well-defined steps that anyone with no prior knowledge could execute (see also: computational thinking), you cannot automate it.

But even if you define a task well enough that anyone could do it, it’s not worth spending the effort automating it if it’s only going to be executed once – it makes sense to automate repeatable tasks. However, do keep in mind that if you have to execute the same change on dozens of devices, you’re effectively repeating the same task, so it might be worthwhile automating even if it’s a one-off change.

To summarize: network automation (or any IT automation) is no different from any other automation, and regardless of what the vendors are telling you, there is no silver bullet. If you don’t know what you want to do, you can’t automate it.


Enroll into Building Network Automation Solutions course if you want to get hands-on experience building your own automation solution, or explore network automation webinars if all you need is familiarity with the technologies, tools and concepts.

This blog post was initially sent to the subscribers of my SDN and Network Automation mailing list. Subscribe here.


  1. > it makes sense to automate repeatable tasks

    There's another aspect of it, though. Even it is a one-off task that will only be applied to a single machine, if you have that configuration in your Puppet/Chef/Ansible/whatever manifests/playbook, you will automatically have *documented* it, just be it being in the manifests.

    Also, even if you are certain something will only ever apply to a single machine, you may suddenly find yourself needing to rebuild/replace that machine, and then it is no longer one-off.

    And once you are able to rebuild your servers/routers/switches at will, you will find uses for that. For example building test machines that are identically configured to your production machines, enabling you to do non-disruptive testing of changes (e.g. software updates).
Add comment