What does good look like?

Automation is a vast subject area that can be overwhelming for the uninitiated. There are a couple of key areas you should be looking for when looking to start automating your network or security infrastructure. These principles are universally true for any kind of automation as well. Always remember to start small because if you start with something modular, scalable, extensible and has a huge ROI, you can continually expand.

What does good look like? Good should contain these four elements:

1. Modularity

2. Scalability

3. Extensibility

4. Huge ROI

1. Modular.

Modular coding means that it's self-contained code that emphasises separating the functionality of a program into independent, interchangeable modules. Each module provides a discreet function all by itself. Too often, programmers build large automation scripts that can't be reused or applied easily to other situations. In layperson's terms, you should create Automation in smaller blocks that can be reused rather than one large block that isn't as easily reapplied to another application. Testing is the best example. Say we need to run some connectivity tests rather than creating a large script for specific ping tests in Cisco IOS and Windows OS. Modular programming would have the Cisco OS and Windows OS in two separate modular automation scripts to be more easily reused or built upon in the future.

2. Scalable.

Heavily reliant on modular programming, we want to create scalable Automation. Even though Automation might initially be designed to provide a single workflow, we build it using tools and software that would enable thousands of workflows. Scalable architecture means we try to eliminate technical debt as much as possible, which is just as true of Automation. Technical debt means any architectural decisions made for a specific function that isn't standard and requires special attention to upgrade. In Automation, we need to ensure our Automation can be easily upgraded with lifecycle upgrades or an increased bandwidth. 

3. Extensible Automation.

Bringing the concepts of modularity and scalability together, you need your automation platforms to be extensible. This means the ability to use your Automation across discreet and variable environments. This is much easier today than five years ago because vendors have come a long way in opening their APIs and interfaces for third-party use. When you don't have extensible Automation, it means more work to develop and maintain. When your platforms are extensible, you have a one-stop shop for developing, deploying and operating your Automation across an environment. 

4. Huge ROI. 

There is nearly no limit to what you can automate, and our resources are finite. Particularly when considering robotic process automation that can mimic a human's actions on a computer. Combine that with the fact that AI is becoming incredibly easy to use, ask Siri, and you can easily be caught up with trying to automate everything. The question is whether developing automation for a particular task is worth the time when you have an entire business of functions to automate - economists call this an opportunity cost. The trick is to identify the workflow you are trying to automate and then identify the parts of the workflow that are either complex or repetitive. Too often, our customers attempt to automate the entire workflow rather than those aspects that provide huge returns on investment in development. Let's say; for instance, you are deploying a new branch. Though possible, you don't need to automate branch deployments to see benefits from automation. What is the workflow involved? A new branch includes design, build, deployment and testing. Designing requires problem-solving, which can be automated to a point, but probably not worth the investment as it's not particularly complex or repetitive. A human can do this relatively quickly anyway. Automating the build, deployment and testing, on the other hand, is boring for engineers and can be 1000 times faster with Automation. A bonus is that if the testing and deployment automation is created in a modular fashion, then it can be reused by the operations team. The takeaway is to focus on only Automation that reduces OPEX by more than the amount it costs to develop. We typically want to see 150% returns as a good marker.