By Alex Henthorn-Iwane, Senior Vice President of Marketing, Gluware
For more than twenty years, the networking industry has expected network automation to become mainstream.
The technology has advanced steadily, commercial platforms have matured, APIs are more common. Open source has lowered the barrier to getting started, and AI is generating even greater interest in automating network operations.
Yet relatively few mainstream enterprises have made network automation the primary operating model for their networks. Per Gartner, most plateau at around 25% coverage.
The usual explanations are familiar. Organizations lack automation skills. Engineers resist change. Leadership doesn’t prioritize automation. Budgets are constrained.
Those factors all exist, but they don’t fully explain what we see.
Most large enterprises already employ capable engineers. Many have executive support, meaningful automation investments, and years of experience. If talent, culture, or determination were the primary constraints, network automation should be much farther along than it is today.
I think the limiting factor is different. For most enterprises, network automation has become an economics problem rather than a technology problem.
More specifically, it has become a problem of engineering capital allocation.
The industry has largely accepted the idea that every enterprise should build and maintain its own device integration layer. Every organization writes its own device interactions, maintains its own parsers, adapts to updated vendor APIs, qualifies software releases, takes the field testing hits to validate accuracy, and continually extends support as the network evolves.
The question isn’t whether engineering teams are capable of doing that work. They are. The question is why they’re committing so much valuable engineering talent to this work instead of focusing on higher-order automation outcomes.
Integration load
Every automation platform must interact with the production network. That means understanding different operating systems, command-line interfaces, APIs, authentication models, software versions, cloud platforms, and legacy infrastructure. Most teams take it as a given that they need to build, own, and maintain these interactions as a set of device integration scripts. None of those integrations are finished once they’re written. They become software that has to be maintained for as long as the device persists in the network.
I call the cumulative engineering commitment required to build and sustain those interactions integration load.
Integration load does not automate the network. It enables automation. That distinction is critical because businesses do not invest in network automation to fund integration work. They invest because they expect outcomes.
They expect network changes to become faster, safer, and more predictable. They expect vulnerability remediation to happen more quickly. They expect compliance to become continuous rather than periodic. They expect fewer outages, lower operational risk, and a network that can keep pace with an environment where AI is accelerating both operational complexity and cyber threats.
From the business’s perspective, integration is simply the cost of delivering those outcomes. It is not one of the outcomes.
The first failure mode: islands of automation
Integration load creates a technical capacity ceiling. Every new vendor, operating system, acquisition, cloud platform, or legacy technology increases the engineering effort required before automation can expand into another part of the network.
Automation usually begins where the integration work is easiest or where the operational need is greatest. Teams deliver useful results. Individual domains improve. Early projects demonstrate clear value.
The difficulty comes after that low-hanging fruit. Each expansion requires another set of integrations, another round of testing, another lifecycle to maintain. Over time, automation coverage grows more slowly as older, less-well-understood devices demand more work to build and maintain integration. The result is a collection of successful automation projects rather than a unified automation capability.
There is a name for this already: islands of automation. Those islands may each deliver value, but due to brownfield realities, most enterprises never reach a point where automation covers and governs the network as a whole.
A network cannot consistently validate changes if significant portions remain outside the intent-based automation framework. It cannot reliably accelerate vulnerability remediation across heterogeneous environments if some platforms require entirely different operational processes. It cannot deliver holistic compliance if policy enforcement depends on which parts of the infrastructure happen to be automated.
The issue for sustaining investment in automation is that the business does not experience automation island or integration challenges. It experiences inconsistent or unachieved outcomes.
The second failure mode: unsustainable economics
Integration load creates a second problem, which is economic in nature. Software products create value by delivering new capabilities. Maintenance is necessary, but it is not the reason the investment was made.
Custom-built integration layers follow the same economics. Every supported platform becomes a permanent engineering commitment. APIs evolve. Operating systems change. Vendors release new capabilities. Scripts require updates. New infrastructure introduces new integration work.
None of this effort is unimportant. But the effort is going toward sustaining the foundation rather than expanding automation. Over time, an increasing share of engineering capacity is consumed by maintaining the integration layer instead of extending automation into new operational domains.
Engineers remain busy, and the automation software continues to function. But a smaller percentage of engineering effort produces outcomes that the business actually recognizes as value.
The enterprise funded network automation because it expected better network operations. It did not intend to become the owner of a multi-vendor integration software product. This is where the investment thesis starts to break down. The issue is not engineering skill or productivity. The issue is the return on engineering investment. In other words, pouring resources into a custom integration layer for a complex, multi-vendor brownfield network is a misallocation of engineering capital that doesn’t lead to promised business outcomes.
AI-driven threats have broken this model for good
This economic model might have been tolerable when automation was primarily about operational efficiency. But that is no longer the environment enterprises operate in.
AI is accelerating vulnerability discovery, exploit development, and attack automation. Organizations need the ability to validate network changes before deployment, execute approved changes quickly, remediate vulnerabilities across diverse infrastructure, and demonstrate continuous compliance.
Those outcomes depend on broad automation coverage. An enterprise that automates only selected platforms cannot consistently deliver them. Integration load therefore becomes more than an engineering burden. It becomes a constraint on operational resilience and cyber risk reduction.
A different allocation of engineering capital
Enterprise engineering teams should absolutely build automation that reflects their business, operational practices, and governance requirements.
They should not have to build and sustain a general-purpose interaction layer for every network technology they operate.
The only sound way to achieve a sound return on investment for device integration within a network automation initiative, in a brownfield environment, is as a platform investment.
This is the thinking behind Gluware’s Device Interaction and Automation Layer (DIAL). Rather than asking every customer to build and maintain its own interaction layer, Gluware invests in supporting network vendors, operating systems, APIs, and command-line interfaces as a shared platform capability. Gluware delivers this capability out of the box, and maintains it on behalf of a broad customer base. Gluware has devoted twelve years and over a million engineering hours (thus far) to building and maintaining this capability.
When customers invest in a platform to handle this layer, they still build automation. They simply direct a far greater proportion of their engineering capacity toward automating their own business instead of maintaining infrastructure that every enterprise requires but none of them actually wants to own. It’s the same logic as investing in a Source of Truth product rather than trying to build your own from scratch.
Committing your team to do even a fraction of a million hours of engineering investment to build, validate, and maintain a brownfield device integration software layer becomes an economic barrier to success. You can’t focus on delivering outcomes, because you’re too overweight on lower-level software components.
Network automation has often been treated as a technology adoption problem. For many mainstream enterprises who are managing a diverse, legacy fleet of network devices, I think it is equally an economic problem.
The organizations that will realize the greatest value from network automation are not likely to be the ones that write the most device integration code. Rather, success in network automation will come to those that devote the largest share of their engineering talent to producing business outcomes rather than maintaining the integration plumbing required to reach them.
