I will soon publish new market research about enterprise network automation strategies. The report is based on a survey of 350+ IT professionals and one-on-one phone interviews with a dozen experts from a variety of well-known enterprises, universities, and government entities.
During my interviews with network automation experts, I concluded the conversations with a variation on this question: "What do network automation engineers fail to understand about your requirements?" As a preview of my upcoming research, here are some of their responses. They should resonate with anyone who has tried to automate a network.
Just Tell Me What Your Good At
“All vendors claim they can do everything. I often ask them to tell me about their core competencies. Don’t sell me on everything. Just tell me what you’re best at and we can work from there. It’s difficult for me to see what they’re good at so that we can position their product in our toolset.”
- IT tools architect, Fortune 500 media company
My Network is More Complex Than You Think
“Some of the off-the-shelf products don’t foresee the production complexity, such as the different vendors we have and how a production setup can be more complicated than what they have in their product. Most of the time, I find myself trying to explain that challenge to a vendor.”
- Network automation engineer, $3 billion SaaS provider
Network Infrastructure Vendors Offer Terrible APIs; Help Me!
“I want to turn my network into an API. My biggest gripe is not with network automation vendors, but network vendors. Their APIs are terrible. This is not an option to just bolt on a toy API. Make an actual API, not just a marketing checkbox thing. A bolt-on API is one that is not very well documented, not very well designed, and doesn’t conform to best practices. You just get the sense that it’s an afterthought. And APIs should be officially supported. I should be able to open a TAC case on it. The reason I am well-paid is because I know how to get what I need from the network without an API, by scraping SSH and things like that.”
- Network automation engineer, Fortune 500 manufacturer
You Need to Test Your Product Against Large Production Networks
“Vendors need to understand that a production network is different from a test environment. A lot of times, I have an issue and a vendor will tell me I need to test it in my lab. A lab has five or six users, but I’m dealing with 50,000 users. Vendors don’t think about how things work under the load of a production environment. They test things in a lab and tell you it works in the real world, and that’s not always the case.”
- Network automation engineer, University medical school and hopsital system
I Want No-Code AND High-Code
"We have a team with different levels of understanding of networking. Some want to work within a system, but others want to go deep and do custom automation. We want to be able to work within a platform at different levels because there are some guys who are low-code/no-code, but sometimes, we have people who want to do the code.”
- Network automation engineer, Fortune 500 food and agriculture company
EMA Perspective
Our research shows that enterprise IT organizations almost always use a mix of commercial and DIY network automaton tools. Rarely is a network automation strategy a "build or buy" proposition. Instead they build AND buy.
On the DIY side, some organizations build out vast libraries of single-use Python scripts. Others use open source tools or develop homegrown software, often with open source components. We believe the prevalence of DIY activity is a direct response to many of the issues cited above. Commercial tools offer polished solutions with strong customer support, but no tool can solve every use case and address every problem. Thus, DIY fills the gaps. In many cases, DIY will be the core of the network automation strategy. If vendors hope to supplant DIY automation, they need to address or help with some of the issues cited above.
