We partnered with EMA Research on a new report to better understand how network and infrastructure teams are really approaching automation — not the hype, but the real-world, script-driven reality. The result is a comprehensive view of what engineers are doing today, why they’re sticking with homegrown solutions, and what leadership is looking for to take those efforts to the next level.
The findings confirmed a lot of what we already hear from our customers: scripting and open source aren’t just a starting point — they’re deeply embedded in daily operations. But they also have real limits. Leadership teams see this clearly, and they’re looking for a way to scale those efforts into something more consistent, secure, and orchestrated.
Here’s what we took away from the report — and what it means for everyone trying to bridge the gap between DIY automation and the demands of enterprise-scale infrastructure.
The Bottom-Up Reality: Scripting Dominates, But Challenges Grow
According to the report, 64% of enterprises rely on homegrown scripts or open-source tools to automate their networks. These DIY solutions give engineers the freedom to adapt to unique environments and solve urgent problems quickly.
But as the report highlights, scripting’s flexibility comes with a cost:
⏱️ 61% of teams spend six or more hours each week just maintaining and debugging these tools.
🚧 Skill gaps and project sprawl make it hard to scale beyond one-off fixes.
⚠️ Security and compliance are constant worries as automations grow.
It’s one thing if I write an awesome script, I share it with my team, and they just hit run. But it’s another thing entirely if I can share that script with them, we can collaborate, and use that code to solve other problems./ That’s way more valuable and impactful to the organization.
Network engineer with a large multi-national pharmaceutical company
The Top-Down Vision: Platforms for Consistency & Scale
At the same time, IT leadership sees the bigger picture: scripts alone can’t deliver the consistent, reusable automation needed across teams. The EMA report found that 64% of IT organizations are actively looking for low- or no-code solutions — not to replace what engineers have built, but to layer in the governance, security, and repeatability that scripts on their own can’t deliver.
Platforms address what DIY tools can’t:
🛡️ Centralized governance and role-based access for safe sharing and collaboration.
🔒 Integrated compliance and security to meet enterprise standards.
🔁 Reusable workflows that can scale beyond a single engineer or team.
🧠 A single orchestration layer to connect and coordinate everything from Python scripts to ServiceNow.
The goal? To create a foundation that scales beyond individual contributors — turning homegrown efforts into consistent, secure, and reusable network services.
The Middle Ground: Operationalizing Scripts, Not Replacing Them
The tension here isn’t about which side is “right” — it’s about how to bridge the gap. Engineers don’t want to rip out what works. Leadership doesn’t want to sacrifice control and governance.
What the EMA report makes clear is that the real opportunity isn’t to pick sides — it’s to bring them together. Teams want platforms that let them start with what they have (scripts and playbooks) and scale into orchestrated, self-service workflows without losing flexibility.
I would like a platform to onboard my scripts, stitch them together, and wrap them in a nice package. I don’t have to tell people to go log into a Linux server and run an Ansible playbook. Instead, they get this nicely named workflow with a nice GUI, and you’ll see little boxes turn green as it progresses through the steps.
Senior Network Engineer with a Midsized U.S. Financial Technology Company
Armstrong’s Journey: From Scripts to Self-Service
One of the standout stories in the EMA report is how Armstrong World Industries made the leap from DIY scripting to orchestrated, self-service network services. They started like so many others: a small team of engineers using Python to automate simple tasks. But as demand grew, so did the burden of maintaining and scaling those scripts.
Armstrong didn’t want to throw away what was working — they wanted a way to make it stronger. By integrating their Python scripts with Itential’s platform, they turned isolated automations into coordinated workflows that could be exposed through self-service APIs and managed securely. The results speak for themselves: 23,000 engineering hours saved and 9,500 days of faster service delivery — all without starting over.
As Armstrong’s engineering lead put it:
We didn’t want to rip out everything we built. Itential gave us a way to bring it all together, make it secure, and deliver it as a product.
How Itential Supports This Journey
At Itential, we’ve seen this pattern play out again and again. Our modular platform is designed to meet teams right where they are — in the middle of that tension between scripts and scalable workflows.
With the Itential Automation Gateway (IAG), engineers can run the scripts and playbooks they already know and trust, in a secure and governed environment. From there, they can orchestrate workflows that span teams, tools, and domains — and eventually expose those workflows as self-service network services that the rest of the business can use.
It’s not about choosing between scripting or platforms. It’s about making sure both work better together.
Operationalizing Automation with Itential
Itential’s modular platform is designed to meet teams right where they are — in the middle of that tension between scripts and scalable workflows.
Purpose-built to bridge the gap between homegrown automation and the enterprise-grade workflows leadership demands.
Itential brings three critical layers together:
1️⃣ Automation Execution: With the Itential Automation Gateway (IAG), teams can run existing Python, Ansible, and custom scripts in a secure, policy-enforced environment.
2️⃣ Workflow Orchestration: Itential’s low-code orchestration engine connects automations across teams and domains, embedding validation, rollback, and compliance at every step.
3️⃣ Productization and & Self-Service: Workflows can be exposed as secure APIs and self-service portals, enabling internal users to safely trigger automated network changes — turning infrastructure into a product, not just a set of manual tasks.
It’s not about choosing between scripting or platforms. It’s about giving teams the flexibility and control to operationalize what’s already working and scale it into something secure, governed, and reusable.
Final Thoughts
The EMA report is a must-read if you’re navigating this evolution. Download it and see how teams like Armstrong are scaling from scripts to services — and how you can do the same without losing what makes your automation work in the first place.
Kristen H. Rachels
Chief Marketing Officer ‐ Itential
Kristen serves as Chief Marketing Officer for Itential, leading their go-to-market strategy and execution to accelerate the adoption and expansion of the company’s products and services.
