While they don’t generally do wholesale rip-and-replace, enterprises working on network automation initiatives confront factors that may result in choosing new equipment providers, at least for segments of the network.
Enterprise network automation initiatives often focus on automating brownfield infrastructure, and many commercial automation tools devote significant resources to communicating with network devices via legacy interfaces, especially proprietary command line interfaces (CLIs). However, our research shows that network automation projects often lead enterprises to adopt new infrastructure from new vendors.
Most of this new vendor adoption is probably isolated to portions of the network, not a wide-scale rip-and-replace of existing infrastructure.
There is a variety of reasons why enterprises might adopt new infrastructure vendors during an automation project, three of which are reviewed here.
Network vendors sell proprietary automation tools
First, many network infrastructure vendors are developing automation technology aimed primarily, if not solely, at their own products, rather than multi-vendor environments. While most enterprises use two or three different automation tools in their initiatives, 42 percent say that an automation tool aimed at a single vendor is part of their strategy. In fact, 26 percent said a single-vendor automation tool is the most important part of their automation technology strategy.
Thus, if a network team determines that a non-incumbent vendor is providing native automation capabilities that best address its requirements, a switch to that vendor may be inevitable, even if it requires an expensive replacement of an incumbent infrastructure vendor.
Embedded zero-touch provisioning
EMA’s research also found that much network hardware with embedded zero-touch-provisioning (ZTP) features are important to many network automation initiatives. Ninety-one percent of surveyed IT professionals expressed interest in ZTP features, and 39 percent said these features are critical to their automation initiatives.
The most important ZTP feature, according EMA’s survey, is software-image auto-updates and verifications. Many enterprises are also interested in being able to custom provision and configure devices via scripts and the ability to unify ZTP network provisioning with compute and storage infrastructure in data centers.
Not every network vendor offers embedded ZTP features on their platforms, and most only offer them on their latest generation products. Enterprises with older equipment may switch to a new vendor during a refresh, and ZTP features may be a contributing or leading driver of that vendor switch.
Network-vendor device APIs
A third possible driver of new-vendor adoption is device APIs. Fifty-two percent of enterprises in EMA’s survey said that network-device APIs are critical to their network-automation initiative. API quality can determine how well network-automation tools can drive change in network devices and extract important data from them. If an enterprise is building its own automation tools internally with Python scripts and open source software, good APIs become essential.
Unfortunately, 95 percent of survey participants reported having difficulty with their network vendors’ device APIs. The biggest issue was cost; 33 percent said their vendor was charging an additional license fee for API use. Twenty-eight percent complained that APIs provided limited access to device data, and 27 percent complained of poor or outdated API quality.
This is by no means an exhaustive list of reasons why an automation project might push an enterprise to work with a new network-infrastructure vendor, but it does offer some clues why it might be a good idea to do so. There are many other factors to consider, including budget, automation business goals, and automation use cases. EMA does not necessarily endorse the idea of vendor replacement during an automation project. In fact, such a change will probably make a project more expensive and riskier. However, it is something to keep in mind as one is researching technology strategies.
This article originally appeared on NetworkWorld.