{"id":6029,"date":"2025-05-18T13:32:14","date_gmt":"2025-05-18T05:32:14","guid":{"rendered":"https:\/\/cicserver.com\/commercial-versus-diy-network-automation\/"},"modified":"2025-05-18T13:32:14","modified_gmt":"2025-05-18T05:32:14","slug":"commercial-versus-diy-network-automation","status":"publish","type":"post","link":"https:\/\/cicserver.com\/de\/commercial-versus-diy-network-automation\/","title":{"rendered":"Commercial Versus DIY Network Automation"},"content":{"rendered":"


\n<\/p>\n

\n

Many people working in IT will be familiar with the \u201cbuy versus build\u201d debate for IT tools and software. Now, that same debate has come to the market for network automation. Where do Network Operations teams fall on this? On both sides at the same time.<\/span><\/p>\n

A 2024 EMA <\/span>analyst report<\/a><\/span> found that most IT organizations (94%, to be precise) cobble together a mix of homegrown, open source, and commercial tools to automate their networks. There is no clear industry consensus on which is better. But that same report found that only 18% of organizations consider their automation strategy a success. Clearly, this approach still needs work. I believe the missing pieces are better automation tools and a shift in the mindset and culture of NetOps teams. Here’s why.<\/span><\/p>\n

Automation helps NetOps do more with less<\/h2>\n

Networks have gotten much more complex over the last few decades thanks to factors like the proliferation of IoT devices, remote work, the rise of software as a service, and software-defined networking. Budgets for NetOps haven\u2019t kept pace with this increasing complexity, however, which leaves today\u2019s engineers trying to do a much harder job with the same resources. That, in turn, has led to greater interest in automation as a way to do more work with the same number of engineers. Unsurprisingly, most NetOps teams want to use automation to improve operational efficiency and reduce security risks. \u00a0\u00a0<\/span><\/p>\n

Related:<\/span>Building a Culture of Automation in Network Operations<\/a><\/p>\n

But there are barriers to automation as well, which helps explain why so few organizations are happy with their programs. Integration issues limit <\/span>network automation<\/a><\/span> tools since enterprise networks use many different devices from many different vendors. The lack of standardization in enterprise networks and the technical debt of legacy components makes this more difficult. Since network automation products are relatively new, many of them have problems with poor API support or inconsistent features. On the business side, limited budgets and limited staff knowledge also hamper automation projects. If IT leadership does not support or prioritize automation projects, they will struggle.<\/span><\/p>\n

Vendor automation is stable, secure, and supported, but can’t do it all<\/h2>\n

Commercial products for <\/span>network automation<\/a><\/span> are guaranteed to meet basic security\/compliance requirements. This makes them a better fit for organizations that must meet stringent regulatory frameworks like HIPAA, SOC2 and SOX. They also offer customer support, which makes troubleshooting and management tasks easier. But because enterprise networks are so complex and customized, there are inevitably some tasks that commercial tools can\u2019t do.<\/span><\/p>\n

Many organizations take a middle ground and use vendor-supported open-source tools like Ansible. This saves budget and provides some assurances for security, compliance and platform requirements. All in all, <\/span>about 70%<\/a><\/span> of vendors use primarily commercial or vendor-supported open-source tools.<\/span><\/p>\n

DIY automation offers customizability and cost savings but not always time savings<\/h2>\n

DIY automation can be tailored to your specific network and, in some cases, to meet security or compliance requirements more easily than vendor products. And they come at a great price: free! The cost of a commercial tool is sometimes higher than the value it creates, especially if you have unusual use cases. But DIY tools take time to build and support. Over 50% of organizations in EMA\u2019s survey spend 6-20 hours per week debugging and supporting homegrown tools.<\/span><\/p>\n

Cultural preferences also come into play. While engineers love to grumble about vendors and their products, that doesn\u2019t mean they prefer DIY. In my experience, <\/span>NetOps<\/a><\/span> teams are often set in their ways, preferring manual processes that do not scale up to match the complexity of modern networks. Many network engineers do not have the coding skills to build good automation, and most don’t think about how to tackle problems with automation broadly.<\/span><\/p>\n

The first and most obvious fix for the issues holding back automation is simply for automation tools to get better. They must have broad integrations and be vendor neutral. Deep network mapping capabilities help resolve the issue of legacy networks and reduce the use cases that require DIY. Low or no-code tools help ease budget, staffing, and skills issues.<\/span><\/p>\n

Second, NetOps needs a culture shift towards automating repetitive things rather than important things. Automation that saves just a few minutes per ticket can be enormously valuable at scale. For instance, one of our customers saved 16,000 troubleshooting hours in one year by automating a series of routine diagnostic tests that used to take 15-20 minutes per ticket. A major enterprise can have 50,000 tickets per month, which comes out to 2,500 to 3,000 hours! Network assessments are another good example. They\u2019re time-consuming to do manually, but once automated, they can be run weekly or even daily. The time spent building them is quickly balanced out by the time saved when human errors or issues are caught early before they affect users or cause outages. \u00a0\u00a0\u00a0\u00a0<\/span><\/p>\n

A final word on net automation build vs. buy<\/h2>\n

For all of these reasons, the mixed approach, with organizations both building and buying network automation, makes sense. It’s rare that one tool can be a perfect solution. Instead, IT needs a portfolio of tools. Improvements in commercial automation tools and a mindset shift among NetOps teams to embrace automation can be the difference between an automation program that\u2019s considered successful and one that isn\u2019t.<\/span><\/p>\n<\/div>\n