The network that runs your business is facing a reckoning. For service providers and data center operators, that reckoning isn’t abstract, it’s existential.
In 75 years, networking has gone through two complete transformations. We’re in the middle of a third. Most organizations are handling it with the thinking that worked for the second.
That’s a problem.
The journey looks like this: networking’s first era asked, “Can networks work at all?” Its second asked, “Can it work better?” Its third (the one we’re in now) asks something harder: “Can it work smarter?” Your answer to that third question will define whether your network is a liability or an advantage in the decade ahead.
Let’s walk through what each era actually meant for the people building and running infrastructure, because the history matters; and because most accounts get the framing wrong.
First Era: From Experimental to Essential (1960s–1990s)
When four university computers first connected via ARPANET in 1969, the question was purely existential: can we make two machines talk to each other at all? By 1983, TCP/IP gave networks a common language. By the early 1990s, the World Wide Web made it real for the masses.
For the engineers who built that era, success meant the network functioned. Period. Uptime was the metric. Connectivity was the goal. The work was hardware, protocols, and specialized talent; all just to achieve basic reachability.
We often take that work for granted now. We shouldn’t.
Second Era: Invisible and Everywhere (1990s–2010s)
The second era changed the measure of success from connection existence to connection quality. Users stopped caring whether they were connected and started caring only when they weren’t.
For service providers, this era meant massive scaling pressure: more subscribers, more devices, more traffic, more SLA obligations. For data center operators, it meant density, redundancy, and the race toward more nines. The job wasn’t just to build connectivity anymore, it was to make connectivity disappear into the background of everything else.
By 2014, over 40% of the global population had internet access. Our industry built that. What your customers experienced as magic was your team’s operational excellence, running 24/7 behind a curtain they never saw.
The problem is that most of the operational models from that era — the tools, the processes, the organizational structures — are still in place. We optimized for scale and reliability using fundamentally human, manual methods. And for a long time, that worked.
It doesn’t work anymore.
Third Era: The Operational Intelligence Gap (We’re Here)
Today’s networks face a categorically different set of demands: AI workloads with asymmetric traffic patterns, zero-trust security architectures layered over legacy infrastructure, hyperscaler competition redefining customer expectations on provisioning speed, and relentless cost pressure compressing margins at every tier.
The promise of intelligent, self-healing networks exists. The reality lags badly behind the marketing.
Even as vendors pitch “AI-driven” and “intent-based” solutions, I see most network teams still configuring devices one at a time, troubleshooting via CLI, and managing security through a collection of disconnected tools that don’t talk to each other. The gap between what the industry is selling and what organizations are actually operating is enormous.
And here’s the thing most people won’t say plainly: that gap isn’t primarily technical. It’s strategic and organizational.
I’ve watched organizations invest heavily in automation platforms that ended up running exactly two workflows eighteen months after deployment; both of which were already being done manually by the one engineer who set the tool up. I’ve seen carriers build brilliant in-house automation that collapsed the moment the engineer who wrote it left, because nobody else understood the codebase and nobody had treated it like production software. I’ve seen automation initiatives stall before writing a single line of code because the network wasn’t standardized enough to automate: every site had bespoke configurations, every region had different naming conventions, and the “automation project” quietly became a documentation and normalization project that nobody had scoped or budgeted.
These aren’t edge cases. They’re the norm. And in every instance, the technology was the easy part.
Build or Buy — And Why That’s the Wrong First Question
When organizations decide to close the operational intelligence gap, the conversation usually lands on a familiar fork: do we build our automation capabilities in-house, or do we buy software and platforms from vendors?
It’s a legitimate question. But it’s the wrong first question, and asking it first gets you into trouble.
Build means investing in internal engineering capability: developers and network engineers who write, maintain, and evolve automation software as a core organizational competency. You own the toolchain. You own the outcomes. You also own every bug, every integration, and every on-call rotation.
Buy means licensing platforms, tools, and software from vendors. You get faster initial deployment, established support models, and someone else managing the underlying software complexity. You also inherit their roadmap, their abstractions, and their definition of what “done” looks like.
Here’s what I’ve learned watching both paths play out: the technical choice matters less than people think. The organizational choice matters enormously.
Both paths require you to restructure how your teams work. Both require leadership that measures outcomes instead of activity. Both will fail if you treat them as technology deployments rather than operational transformations.
The difference is who your platform team is. If you build, your platform team is internal; engineers who treat the network as a software system and support operations teams the way a product team supports users. If you buy, your platform team is partly external; the vendor’s engineers and your internal staff who interface with them. Either way, that team needs to exist, needs to be empowered, and needs a clear mandate that isn’t just “keep the lights on.”
What I’ve also seen is that the buy path creates a particular failure mode: organizations assume the vendor handles the hard part, so they underinvest in the internal capability to use, integrate, and evolve the tooling. The automation silo between the network team, security team, and application teams remains intact. Automated changes that cross those boundaries still hit manual approval gates that take longer than the old process. The tooling is real. The speed gain is not.
There is no technology purchase that solves a people and process problem.
Three Pillars, Regardless of Path
Whether you build, buy, or some combination of both, closing the operational intelligence gap rests on the same three capabilities:
Automation. Replace manual, repetitive configuration with code. This isn’t about eliminating engineers. It’s about eliminating the work that prevents engineers from doing anything valuable. Changes that take weeks should take minutes. Toil that fills senior engineers’ days should be handled by systems.
Observability. Move beyond reactive monitoring. Basic alerting tells you something broke. Observability tells you why, where in the system, and what else it affects. For service providers and data center operators, the difference between those two isn’t a technical nuance, it’s an SLA.
Orchestration. Build abstractions that hide network complexity from the teams and clients who don’t need to understand it. Application teams should be able to request network services without knowing what’s underneath. That’s not dumbing things down; it’s what actually enables the business to move at speed.
These three don’t work in isolation, and they don’t work without the fourth ingredient: a culture that rewards experimentation instead of punishing failure.
The People Problem Nobody Wants to Own
This is where most transformation initiatives quietly die.
Technology transformation is, honestly, not that hard. The cultural shift required to use it is significantly harder. I’ve seen automation tools collect dust because the teams that were supposed to use them weren’t rewired to work differently, and nobody in leadership owned that problem. The tool got blamed. The real issue was never addressed.
Success requires teams that are genuinely restructured across network, security, and application boundaries; not just org chart adjustments, but actual changes to how work flows between groups. It requires leadership willing to redefine what good looks like: not tickets closed, not change freeze compliance, but business outcomes. Mean time to recovery. Provisioning cycle time. Defect escape rate.
It also requires accepting that when you measure the right things, the early results often look worse before they look better. Organizations that can’t tolerate that period don’t complete the transformation.
Your Mandate
The intelligent network isn’t something you evaluate anymore. Parts of it are already operating in your competitors’ environments. The question isn’t whether your network operations will transform, it’s whether you drive that transformation or respond to someone else’s.
For service providers: the carriers who can provision faster, respond to incidents smarter, and scale without proportional headcount growth will take the enterprise contracts. The ones who can’t will lose them.
For data center operators: the operators who can demonstrate operational intelligence — real observability, automated remediation, verifiable compliance — will command the premium contracts. The ones running on tribal knowledge and CLI heroics will compete on price until they can’t.
Your mandate is to close the operational intelligence gap. That means choosing your build-vs-buy path deliberately, investing in the organizational and cultural changes that make either path work, and measuring outcomes that matter to the business, not just to the network team.
The third era demands more than new tools. It demands new thinking, new structures, and leaders willing to make both happen.
Ready to move from diagnosis to action? Khadga Consulting helps service providers and infrastructure operators close the operational intelligence gap — technology, culture, and all the uncomfortable parts in between. Let’s talk.
