Network Automation …“Why Would I?” to “I already am!”
I have spent the last few days reaching out to colleagues to gather more data on what senior IT managers with responsibility over network teams think about network automation. These organizations are all pretty significant in size and represent Federal, Public Sector, and commercial enterprises.
I posed the following questions:
Are you using network automation?
If not using network automation, why not?
Any general comments back on network automation in the future
Are you using network automation?
The overwhelming answer (surprisingly) was “yes”. However, the meaning varied wildly.
If so, how?
Again, the surprising answer was: “With the tools provided by my networking vendors.”
Internal or external software developers
Only in one instance was in-house network automation software developed requiring network engineering personnel to dedicate themselves to software development.
How many FTEs (Full-Time Equivalent)?
There were 1.5 FTE’s developing the software and then subsequent maintenance/updates. Other than the one example above, the majority of the software development efforts within the network teams are productivity enhancement tools that the teams have developed for themselves internally.
If not using network automation, why not?
All the organizations were using some level of network automation (as they defined it) and watching the industry closely for products that can solve specific problems for them or offload work from staff.
Any general comments back on network automation in the future?
The one organization that had invested in an in-house network automation application did so to solve a particular problem. They were pleased with the results, but it cost them 1.5 network engineers dedicated to the project and the on-going battle to fund the effort. They have been reviewing industry offerings to replace that tool. Not because they are unhappy with it, but the key developer is talking about retiring and the part-time person is not confident they can support the software.
My canvas of leadership was surprising.
Common threads:
Yes we have network automation
No, I do not want to undertake any in-house development. I can only “sell” to my management “store bought” network automation which comes with support even if it does not do everything that I need.
Almost all efforts were internal to the network team. That is, individual or team productivity rather than cross team services for improved business outcomes.
Let's explore the reluctance of in-house software development.
They were extremely hesitant to invest in in-house development efforts for several key reasons:
Local staff will probably be limited and supporting software development efforts will take them away from their traditional network engineering roles. Network engineers who transition to software development roles have to be backfilled. The work hasn't gone away, now the company has to fund the additional people.
What if the developers leave, how do they support the software/tools?
Everybody was firm about prioritizing vendor-supplied tools (even the one company that had “grown” some internal resources). Vendors typically have larger staff, have 24x7 support, on-going updates, bug fixes, and can provide training and documentation on their products. Granted the vendor-provided tools can be extremely expensive and may not meet all the needs of the organization. Managers weighed that cost versus losing internal resources which are limited, doing their own support, and concerns about transitioning tool development in the event of a personnel change.
Hidden Issues Come To Light with Vendor Software
Many vendor-supplied tools require significant hardware standardization to function properly. Typically networks will evolve over the years based on changing requirements, custom needs, and quite frankly; budgets. It’s not unusual for vendor solutions to only support 60-70-80% of the network, unless you are willing to spend time, effort, and money to retrofit higher levels of hardware standardization. It’s frustrating to pay significant amounts of money for a solution, AND have to do significant amounts of expensive replacements to ensure that more of the vendor’s automation solution works.
There was also a great deal of annoyance with vendors not being able to support larger groups of non-standardized (legacy) hardware. Vendors who show up with the ability to support more hardware will be favorably looked upon. The folks I talked to shared many of the same stories of well-known and extensively used software packages that turned into a nightmare when it came time to actually deploy them.
Regardless, a consistent response was “we will take a vendor supported partial solution over an in house effort”.
Did I hire a network engineer or a software developer?
At the end of lots of discussion, management folks seem to be hesitant to lose highly capable network engineers to software development efforts. Those local people are clearly the best to do the work as they are most familiar with the local infrastructure and environment. Transitioning them to software development has potential long-term gains, but has an immediate negative impact to the organization with the loss of their talents in their traditional role.
So quite a pickle.
Leadership: “Sure we are doing network automation. What’s all the fuss about?”
Rank & FIle: “Huh?”
In the immortal words of Inigo Montoya (The Princess Bride)…
“You keep using that word (automation). I do not think it means what you think it means.”
On the one hand we have an entire community organized around the premise that we have not seen full adoption.
On the other hand leadership is saying, “of course we have network automation”!
There is a significant gap here that needs to be addressed
