If you’re in IT, chances are you’ve automated some task before. Whether it’s writing a script, building an application yourself or leveraging an off-the-shelf solution from a vendor; you’ve automated.
Automation takes away the tedious, repetitive tasks that humans are prone to error doing and allows us to focus on the more critical, creative works. Just because we have all automated before doesn’t necessarily mean we would be successful in IT automation. Those of us that don’t have an automation mindset will fail given a massive company initiative to save money by automating. Even a department project to cut down on time people are spending creating users in Active Directory would be a massive undertaken without the proper approach to automation. Building useful IT automation that saves time, cuts down on errors, and doesn’t require a lot of maintenance is a lot harder than one may think.
A lot of people I’ve seen in my career treat automation as an afterthought. It’s a process that gets forced upon them when they can’t keep doing all of the manual tasks they’re used to. This isn’t necessarily because they don’t want to; they don’t think about it. The need for automation isn’t as strong if you’re only performing a task once per month vs. once per day. Also, when starting a new project, a lot of people can’t even document things let alone come up with specific processes and procedures to correctly implement an automation routine!
Any script, application, or service that leverages some form of automation must understand the process that’s being automated. To understand a process is to document the rules of how the process goes from point A, to point B, to point C. If you’re too busy to record and merely turning knobs and flipping switches to get a process to work, you’ll have no way to know what was done. Trying to implement automation in this situation is a fruitless endeavor.
Automation-first thinking designates documentation as priority #1. It’s impossible to automate a process without first correctly understanding the steps involved. To truly succeed at any automation effort first requires being able to perform the entire procedure from start to finish more than once. You can’t replicate a process that you don’t understand. This is the first step.
Once you’ve got the documentation to replicate a process in place, the second step is to consider the parameters. After all, just because you can replicate a method doesn’t mean it’s going to be the same every, single time. You must consider all of the parameters that may change when this automation effort is executed over time. For example, this mindset is related to a scripting concept some call tool-making. PowerShell tool-making is a popular term in my niche. I teach that you can create a script, but you should focus on creating tools instead. The difference is a tool can be used over and over again in different contexts with no changes to the code itself; just how it’s invoked.
The concept of tool-making can be extended across lots of different automation projects. It’s important to think about a solution that’s flexible and can be invoked in different ways. If you have to create a different automation routine every time, then you might as well do it manually!
Wrap Up
At the end of the day, automation first thinking is about:
- Documenting everything from the start
- Considering how each piece in the process interacts with others
- Designing a flexible solution
Even though you may not automate a particular process, treating it like you are will help you understand it better and come up with documentation that will enable your peers to more easily get up to speed.