Global capability isn’t about owning networks, it’s about orchestrating them
What global network orchestration actually means
For most of the history of enterprise networking, one principle held everywhere: the party that owned the infrastructure was the party that managed your network. A multinational bought from a global telco and depended on that provider’s assets to reach every location. A regional business worked with a regional carrier on the same basis. Ownership and management were the same thing, and in a world of closed private networks connecting physical offices to physical data centers, that was a reasonable arrangement.
That world has gone, and I won’t labor the point because we’ve covered it at length elsewhere. My co-founder Tim recently argued that competitive advantage in enterprise networking has shifted from infrastructure ownership to operating models. This article is about what that shift looks like in practice: what the orchestration work actually involves, layer by layer, and why it’s now the capability that matters most. The perimeter has dissolved, users connect from anywhere, workloads sit across multiple clouds, and the Internet has become the default transport for almost every enterprise network. The requirement hasn’t simply shifted from “owns the infrastructure” to “uses the Internet.” It has shifted to something more specific and more difficult: the ability to integrate and orchestrate a large number of disparate components, at every layer of the solution stack, into a single coherent outcome for the enterprise.
The underlay is now a portfolio of options
Let’s start at the bottom, and I would argue, the most essential part of a global enterprise network to get right. The optimum underlay for a global enterprise today is rarely a single provider’s footprint. It’s a deliberately fragmented mix: local ISPs chosen market by market, site by site; metro fiber where it’s available, LEO satellite where it changes the outcome for remote or hard-to-serve sites, 5G for rapid deployment and diversity. Assembled well, this mix delivers more bandwidth, better performance, and faster lead times than any single-provider model can, often at lower cost.
But “assembled well” is a lot more difficult in practice. This approach means dealing with dozens or hundreds of providers, each with their own operating model, their own performance characteristics, their own quirks and failure patterns. A regional ISP in Southeast Asia does not behave like a metro fiber provider in Germany, and neither behaves like a LEO service. Multiply that across a global estate and the coordination problem is far beyond what spreadsheets, escalation matrices, and goodwill can handle.
The only way to run this well is through data. These networks generate enormous amounts of telemetry, and the operational challenge is less about collecting it than interpreting it: learning the normal behavior of each provider and each link, detecting the anomalies that matter, and knowing what to ignore. A link that shows periodic packet loss at 3am during a provider’s maintenance window is noise. A gradual latency shift on a path carrying a manufacturing plant’s OT traffic is a signal. Distinguishing the two, at scale, across hundreds of underlying providers, is the foundational capability of the modern model.
Network orchestration compounds at every layer of the stack
The same requirement repeats at each layer above, in different forms.
At the overlay, traffic between a user and an application can now take many paths: direct to Internet, through a regional hub, across a middle-mile backbone, via a cloud provider’s own network. Multi-cloud connectivity adds topology decisions that simply didn’t exist in the hub-and-spoke era. None of these choices are set-and-forget; the right answer changes as applications move, providers evolve, and traffic patterns shift. Someone has to be continuously engineering this, with a clear view of the outcome being optimized for.
At the security layer, Zero Trust principles have to be translated from architecture diagrams into enforced reality: controlling exactly which traffic is permitted between users and workloads, reducing the attack surface as the network becomes more open by design, and integrating identity, access, and inspection components that frequently come from different vendors than the network stack. Security and networking decisions are now the same decisions, made in the same designs, and orchestrating them separately produces gaps that show up in audits at best and incidents at worst.
At the top sits the analytics layer, where all of this has to become intelligible. Enterprises increasingly, and rightly, expect to consume operational data in multiple ways: through dashboards, but also through APIs feeding their own systems and, increasingly, their own AI tooling. The value is in normalization, correlation across layers, and the business context that turns “this link degraded” into “these two plants are at risk and here’s the remediation already underway.”
The stack is now unrecognizable, but the service cannot be
There’s an underlying tension that makes this really difficult. Everything underneath has been transformed: hundreds of ISPs instead of one carrier, multi-cloud instead of data centers, software-defined networking, security woven through the fabric, AI assistants in the vendor products. But from the enterprise’s perspective, certain things must remain predictable. There is still an incident at 2am that needs a disciplined management process. There is still change management, problem management, and release management that the business depends on running the same way every time. The CFO still wants one accountable party.
So the real capability is delivering traditional operational structure over a very non-traditional foundation. The processes the enterprise experiences should feel as stable as they did in the private network era. The layers underneath, which is what makes those processes work across this fragmented modern stack, have to be rebuilt around data, automation, and integration expertise. Providers who have modern technology but improvised operations fail one way; providers who have mature processes designed for a single-carrier world fail the other. The orchestration model requires both, and that combination is rarer than it should be.
Parity with private networks is the wrong goal
One final point that comes up in many conversations I have with enterprises. When enterprises evaluate this model, the implicit question is often defensive: can an Internet-based, multi-provider network possibly be as good as our old private network? That’s the wrong bar, because it’s a low one. Private networks were expensive, slow to change, very bandwidth-constrained, and not at all able to identify user experience gaps.
The goal of the orchestrated model is to greatly exceed that baseline: multiples of the bandwidth at comparable or lower cost, sites going live in weeks rather than months, true path diversity instead of just redundancy inside one provider’s network, and visibility deep enough to fix problems before users report them. Enterprises achieving those outcomes today aren’t achieving them despite the fragmentation of the underlying components. They’re achieving them because someone is orchestrating that fragmentation deliberately, extracting the best from each component, and binding the whole thing together with data.
How to evaluate a global network partner: the questions that matter
If this model is where the value sits, the evaluation framework for a network partner changes accordingly. Network maps and PoP counts tell you almost nothing. The questions that matter are about orchestration capability. How many underlying providers do they actively manage, and how do they hold each accountable? Show me the data platform: how do they learn baselines, detect anomalies, and decide what to act on? How do they integrate the security layer rather than bolting it on? Can I consume their operational data through APIs into my own systems? And how do they maintain rigorous incident, change, and problem management across components they don’t own?
The infrastructure owner model made sense in its era. The era ended when the Internet became the enterprise transport of choice. What replaced ownership as the source of capability is expertise: in integration, in data, in extracting performance from imperfect components, and in wrapping the result in operations an enterprise can build on. Global capability now belongs to whoever orchestrates best.
How should CIOs evaluate network operational models
Perhaps we therefore need to change the question. Instead of asking: “Should we outsource our network?” CIOs should ask:
- Where should control sit?
- Which decisions genuinely require internal business context and judgement?
- Which activities benefit from specialist expertise, scale and 24×7 capability?
- Which operational activities shouldn’t be performed by either party because they can now be automated?
- Where would shared visibility and collaboration produce a better outcome than either organisation working independently?
Those questions lead to a different conversation from the traditional outsourcing debate. They start with the outcome and work backwards towards the operating model required to deliver it.
The future of enterprise network management
In the first article in this series, I argued that competitive advantage in enterprise networking has moved away from infrastructure ownership towards operating model, software, automation and outcomes.
That shift has implications for how enterprises choose to operate network and security in the future. The evolution isn’t simply from outsourced to DIY. It is towards something more nuanced: intelligently shared and increasingly automated.
The risk MNCs need to avoid is incremental optimisation. Renegotiating connectivity contracts or improving the terms of an inherited outsourcing model may deliver savings, but it doesn’t answer the more important question: is the underlying model still right?
CIOs, IT teams and procurement should challenge the architecture, sourcing model and division of responsibilities rather than simply replicating the RFPs of the last decade. Engage new voices in your deliberations and start with the outcomes in mind, not the inherited model.
Enterprises shouldn’t have to choose between control and capability. The optimal operating model must give them both.
