Enterprise Network Modernization, Part 1: Draw the Map Before You Buy the Boxes

Ask five people in the same company what “network modernization” means and you will get five answers, each one shaped by the last vendor presentation that person sat through. One will say SD-WAN. Another will say SASE, or zero trust. The data centre folks will talk about AI fabrics and 800G optics. The cloud team will tell you the network is somebody else's problem now, it lives inside a VPC. And someone from finance will ask why all this costs so much and whether we can just rent it.

None of them is wrong, which is exactly the problem. Everybody is describing one piece and nobody is holding the whole thing. So the roadmap turns into a shopping list, the shopping list turns into a set of projects, and a few years later nobody can quite say who asked for what, why, or whether anything actually got better.

I wrote about the same itch for security a while back (The Enterprise Security Meta Model). Same spaghetti, different kitchen. This post is the networking version, and then a second part on something that bothers me even more: once you have the map, where do you get the evidence to decide anything?

If you are an executive, the map and the evidence section are the parts to read, and you can skim the technical asides. If you run or design networks, the asides are for you, and I would like to hear where you disagree.

Why I start with a map

Without a shared map, three things tend to happen.

First, overlap. Two teams quietly buy the same capability under different names. The firewall team and the WAN team both end up with a cloud security service, each with its own policy engine, each convinced theirs is the strategic one.

Second, gaps. Something important has no owner, and it is usually the thing that sits between two teams. Who owns the path from a branch office to a SaaS application? Ask three people, get three answers, and a fourth who says “it depends”.

Third, sequencing mistakes. Agentic operations get funded before anyone trusts the telemetry. Segmentation projects start before anyone knows what talks to what. You can guess how those go.

There is a second reason, and it is less obvious. Categories keep moving. Gartner published a Magic Quadrant for Single-Vendor SASE in mid-2024. A year later the same space was being evaluated as SASE platforms, and the 2026 edition is dated July. The technology did not change overnight. The label did. If your strategy is organized around somebody else's category names, it ages with their marketing calendar. I would rather own the map and then lay the analyst categories on top of it.

The map

Two questions organize the whole thing. Where does the traffic live? And what governs it? The first gives four domains. The second gives three planes. Under both sits a physical foundation that nobody wants to talk about and everybody depends on. 

That is 24 topics plus the foundation. It is not a magic number, it is just where I ended up after moving things around many times.

The one rule that makes it work: every topic has exactly one home, and the home is decided by who owns the buying decision, not by what the product brochure says. Consultants call this mutually exclusive and collectively exhaustive. I just call it not double-counting.

So SASE platforms sit under WAN, because that is where the traffic path gets bought, even though half of what they do is security. Quantum-safe appears once, under security. Segmentation appears once, under security, even though it gets enforced in campus switches, in DC fabrics and in cloud constructs. The moment you let a topic appear in two boxes, the map turns into a pile of overlapping boxes, and a pile is not a map.

Where the traffic lives

Data center. This is where the money and the heat are. Enterprise DC fabric is the familiar leaf-spine, EVPN-VXLAN world that carries the applications you already run. AI fabric is a different animal: the back-end network that ties GPUs together, with a few enormous, synchronized, loss-sensitive flows instead of lots of small ones, and the Ethernet or InfiniBand debate that comes with it. My view, and it is only a view, is that most enterprises are not building GPU clusters. They are renting capacity or calling APIs, and for them the AI question is less about 800G switches and more about connectivity, data movement and security around that rented capacity. Whether you need the AI fabric topic as a priority depends on which of those two worlds you actually live in. Edge or micro-DC is compute pushed closer to where data gets created, such as stores, plants and branches. The network question there is mostly about how many of them you will end up with and who is going to run them.

Campus and branch. The least glamorous domain and the one most of your users actually touch. Wired and wireless LAN are where Wi-Fi 7 and its predecessors live. Private 5G is for the cases where Wi-Fi is the wrong tool, such as large sites, mobility, or industrial areas. IoT and OT networking covers the devices that cannot run an agent, cannot be patched on your schedule, and were sometimes bought by a department that never told IT.

WAN and secure access. SD-WAN is the overlay that steers traffic across whatever transport you have. SASE platforms bundle that with cloud-delivered security, and the interesting argument inside most organizations is whether the network team or the security team owns the decision. Carrier WAN services are the underlay: the ISPs and telcos that carry it all, and the contracts that make switching hard. Optical or photonic transport sits below that, and it matters when you need a lot of bandwidth or predictable latency between a handful of sites. The conversation moves down the stack, and the people you need in the room change.

Multi-cloud and hybrid. Native cloud networking is every cloud's own constructs (VPCs, VNets, transit gateways), each slightly different. Multi-cloud platforms try to give you one policy and one view across them. Cloud connect, or SDCI, is the software-defined private on-ramp to those clouds. Service mesh and PaaS overlays are application-level networking inside platforms like Kubernetes, and they are usually owned by platform teams, not network teams, which is where a lot of quiet friction comes from.

What governs it

Operations and intelligence. Three items, and the order matters. Observability and digital experience is how you see. Automation and orchestration is how you act, deterministically, from a specification. Agentic NetOps is how you let software decide, and that is a different thing from automation, not a bigger version of it. Automation is governed by the spec: it either does what was written or it does not. A learned system is governed by measuring its behavior over time, with confidence levels and drift. Treat them as the same thing and you will govern one of them badly. You cannot automate what you cannot see, and you should not let an agent act on what you cannot verify.

Security and trust. Zero trust and segmentation is deciding who may talk to whom, and it is hard because it is mostly an organizational problem wearing a technical costume. Hybrid mesh firewall is the idea of consistent firewalling across on-prem, cloud and branch under one management plane. Quantum-safe is about cryptography that survives a future quantum computer, which matters now because some of what you send today will still be sensitive then. Network security basics is the unglamorous baseline controls that still need to be in place before anything fancier is worth discussing.

Consumption and sourcing. NaaS is a commercial model, not a technology. What you are really buying is a contract, so read the exit terms before you read the brochure. Managed and co-managed services answer a different question: who runs it, and who carries the pager.

Foundation. Fibre, cabling and optics. Twenty-year assets, slow to change, and the mistakes here are the most expensive to reverse.

What the map does not cover, and where it is weak

Satellite and LEO connectivity, DNS and IP address management, voice and collaboration, and whatever 6G turns out to be are not on it. Add them when they matter. The structure should make it obvious where they would go.

It is also not perfect. SASE straddles two worlds and any placement is a compromise. Edge or micro-DC could just as easily live under campus and branch. And a map is for deciding what to talk about, not for designing anything. A design still needs requirements, constraints and trade-offs, and no box on a slide replaces that.

What to do with it

Twenty-four topics cannot all be priorities, and if they are, nothing is. Pick a few. For an exercise like this, four to six is plenty.

For each candidate, five questions, in plain language:

1. What business outcome is pulling on this? If you cannot name one, stop here.
2. Where are we today, honestly?
3. What breaks, or gets expensive, if we do nothing until 2030?
4. What does it depend on? SASE depends on identity being in reasonable shape. Agentic operations depend on observability and automation. Segmentation depends on knowing what talks to what.
5. What evidence do we have, and how good is it?

The fifth one is where most plans quietly fall apart, so the rest of this post is about that.

What comes next

The map tells you what to talk about. It does not tell you what to believe. In Part 2 I cover where I look for evidence before any of these topics gets a budget, how I read analyst reports without being fooled by the top right corner, and why I rate the evidence separately from the technology.  

HTH...

A Tech Artist 🎨