Is network automation adoption necessary?
Automation is not a one-size-fits-all strategy for every network problem. Enterprises must examine their network's needs to determine if automation is a worthwhile investment.
Enterprises, vendors and network professionals alike hail network automation as a necessity. The truth is, though, not everyone needs network automation.
Once, professionals approached automation with unease, fearing the technology would replace their jobs. Those fears eventually changed to acceptance after automation proved to support -- not replace -- their responsibilities. Now, some professionals question if all enterprises really require network automation, as discussed in a panel discussion with the On-Premise IT podcast.
Enterprises cannot apply automation as a one-size-fits-all strategy to every networking problem. Before automating, network teams must discern which problems automation can solve and figure out the cost-benefit analysis of implementing it.
The range of automation
Implementing network automation isn't as simple as flipping a switch. Automating every component in a network is seldom a wise choice. During the podcast, network architect Jake Khoun explained that total automation can leave IT departments understaffed and overworked, unable to maintain existing networks.
"You have to maintain the balance and apply it strategically," Khoun said.
Striking that balance comes with understanding what automation is and isn't. Tim Bertino, a solutions engineer at Cisco and co-host of The Art of Network Engineering podcast, encouraged network pros to be aware of the following three things when undertaking automation:
- Abstraction.
- Orchestration.
- Automation.
Both abstraction and orchestration might include elements of automation. For example, automation can connect multiple orchestrated tasks -- "true automation" as Bertino called it.
Automation in abstraction can prove similarly beneficial, especially in meeting network compliance standards, the panelists said. Engineers can save time if they automate relatively simple configuration tasks across hundreds of devices. Automating to abstraction also enables platform flexibility, Khoun added. Networks can then perform daily tasks without vendor restrictions.
"If you're going to automate," Khoun said, "automate to an abstraction."
Does automation address network problems?
Before building or buying network automation tools, IT teams must be aware of problems within their networks. One of the goals of automation is to remove human error from network operations. Without first checking the network, engineers risk perpetuating existing, unrecognized problems, according to the panelists. This can result in unnecessary automation that complicates the network rather than makes it more efficient.
"You need to have a problem in search of a solution rather than a solution in search of a problem," Bertino said.
Enterprises should not overlook initial network design. According to the panelists, many of the problems within a network are the result of fixable bad practices. In these cases, defaulting to automation won't solve the problems within the network; it might make the network fail faster. Fixing bad practices could address these issues, eliminating the need for automation.
Addressing bad practices is also cost-effective. Building automation toolsets enables staff to pinpoint their specific network problems. However, this could be a waste of time, money and resources, Khoun said. Enterprises risk investing resources into a piece of automation that only current staff are familiar with and new engineers don't know how to support. Further, in-house automation platforms might only address a fraction of network issues and exacerbate others.
Buying vendor automation platforms and integrating them into enterprise networks might not be the right strategy, either. Vendor platforms are not nearly as customizable and work best with other same-vendor products. As such, engineers risk vendor protocols restricting automation capabilities.
Even after IT teams address bad practices and determine the inherent network design is strong, the problems might persist. Still, enterprises haven't wasted their time in trying to mend bad practices or reconfiguring the network. Sometimes rearchitecting and changing network processes are necessary for automation integration, said Tom Hollingsworth, host of the On-Premise IT podcast.
Problems around policy, plan or design execution are areas where network engineers should evaluate the potential for automation. Automation tools can target the primary issues and lessen the team's workloads and network errors. Engineers can then address the trickier, more complex problems in the network.
Determining if automation is necessary
Again, there are network problems that automation not only won't solve but might also exacerbate. IT teams must implement automation where it makes sense. If they don't, automation only adds more problems to network managers' workloads. To determine if automation is right for them, the panelists suggested that enterprises ask the following questions:
- What problems need to be solved, and who do they have to solve them?
- What is the skill level of the IT teams?
- Will it cost more time, money and resources to hire skilled automation engineers or to train existing engineers?
- Do IT teams need to automate anything?
- How closely is what the network does tied to how the enterprise makes money? How closely is network operations aligned with whatever gets everyone paid?
- Is the network a hindrance to operations? Do admin teams have to sit and wait on building and configuring the network before they can do what they need to do?
Nicole Viera is an assistant site editor for TechTarget's Networking site. She joined TechTarget as an editor and writer in 2024.
