Automation Is Not Your Enemy.

Sun Tzu wrote that you cannot win if you do not know your enemy and yourself. In his sense, he was talking about knowing your army and its capabilities, but this rule seriously applies to nearly every endeavor, and certainly every competitive endeavor. Knowing your own strengths and weaknesses - In our case the strengths and weaknesses of IT staff and architecture – is imperative if you are to meet the challenges that your IT department faces every day. It is not enough to know that you must do X, you must know how X fits (or doesn’t!) into your architecture, and how easily your staff will be able to absorb the knowledge necessary to implement X.

Take RSS feeds for example. RSS is largely automated. But if you receive a requirement to implement RSS in the corporate intranet or web portal, the first question is “can the system handle it?” If the answer is no, the next question is “can staff today implement it?” If the answer is no, the next question is “do we buy something to do this for us, or train staff to implement a solution?” Remember this is all hypothetical. Unless you had very specific needs, I would not recommend training staff to write an RSS parser. At best I’d say get a library and train them to use calls to it… Which does indicate a corollary to this point of Sun Tzu’s… Know the terrain (in this case the RSS ecosystem) in which you will meet your enemies.

Sun Tzu, courtesy of Wikipedia

By extension, knowing the terrain implies “have some R&D time in normal workloads”. I’ve said that before, but it’s worth saying over and over. Sure, some employees might waste that R&D time. Some won’t. Ask Google. It doesn’t have to be some huge percentage, just don’t ask your staff to be up-to-date on things they don’t have time to go research. But I digress.

As virtualization and cloud grow in importance, so too does the ability to automate some functionality. As end user computing starts to utilize a growing breadth of devices, automation starts to gain even more imperative. Seriously, on my team alone we have Android, Blackberry, and Apple tablets, Apple and Blackberry phones… And we’re all hitting websites originally designed for Windows. The ability to serve all of these devices intelligently is facilitated by the ability to detect and route them to the correct location – and to be able to monitor usage and switch infrastructure resources to the place that they’re most needed.

Some IT staff reasonably worry that automation is going to negatively impact their job prospects. Network Admins in particular have seen many jobs other than theirs shipped off-shore or automated out of existence, and don’t want to end up doing the same. But there are two types of automation advancement, those that eliminate or minimize the need for people – as factory automation often does to keep expenses down – and the type that frees people up to handle greater volumes or more complex tasks – as virtualization did. Virtualization reduced the time to bring up a new server to near zero. That eliminated approximately zero systems admin jobs. The reason is that there was a pent up demand for more servers, and once IT wasn’t holding requests up with cost and timing bottlenecks, demand exploded. Also, admins had more responsibilities – now there were the host systems and dozens of resident VMs.

The same will be true of increasing network automation. Yes, some of the tasks regularly done by network admins will get automated out of existence, but in return, managing the system that automates those tasks will fall upon the shoulders of the very administrators that have more time. And the complexity of networks in the age of cloud and virtualization is headed up, meaning the specialized knowledge required to keep these networks not just working, but performing well will end up with the network admins.

Making network  automation an opportunity, not a risk. An opportunity to better serve customers, an opportunity to learn new things, an opportunity to take on greater responsibility. And make things happen that need to happen at 2am, without the dreaded on-call phone call.

We at F5 have been calling it “ABLE infrastructure” to reference our network automation efforts, and that’s really what it boils down to – make the network ABLE to do what network admins have been doing, so they can do the next step, integrating WAN and cloud as if it was on the LAN, and dealing with the ever-growing number of VMs requesting IP addresses. And some R&D. After all, once automation is in place, another “must have” project will come along. They always do, and for most of us in IT, that’s a good thing.