As workloads spread across cloud, edge and on-premises environments, network designs built around centralized infrastructure may no longer deliver the performance, security or flexibility businesses need. Longstanding assumptions about predictable traffic patterns and trusted internal networks can create bottlenecks, security gaps and other challenges.
Technology teams must determine which established network-design practices still make sense and which need to change to support more distributed operations. Below, members of Forbes Technology Council share longstanding network-design assumptions worth reconsidering and explain how businesses can adapt their approaches.
1. Anchor Security To Identity, Not Location
The assumption I’d revisit is that your network still has one front door. Workloads now run across cloud, edge and on-prem, so security needs to follow identity and applications, not a physical location. – Victor Cardona, SecureX
2. Limit Network Access To What’s Needed
I think we need to stop treating broad network reachability as the starting point. We spend a lot of effort connecting campuses, clouds and data centers, only to add layers of policy to restrict communication afterward. Instead, we should design connectivity around what each user, device or workload actually needs to reach, with those boundaries enforced by the network from day one. This would greatly reduce exposure and operational complexity. – Jaswanth Kongara, Nile
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
3. Expand Visibility Across Distributed Environments
Businesses should revisit the assumption that they know where their network begins and ends. As application traffic moves between cloud, edge and on-premises environments, it crosses boundaries traditional monitoring tools weren’t designed to see. Network design must account for this movement, with end-to-end visibility into how these environments work together to deliver services. – Pavel Bykov, IP Fabric
4. Distribute Data To Maintain Application Availability
Businesses should rethink the assumption that applications can always rely on a centralized data infrastructure. As workloads span regions and environments, networks must be designed for inevitable disruptions, not perfect connectivity. That means distributing data closer to applications while maintaining consistency, low latency and availability even when connections or entire regions fail. – Karthik Ranganathan, Yugabyte
5. Support Local Processing When Cloud Connectivity Fails
Stop assuming that everything needs to route through a central cloud or data center. As workloads spread, the network must support decisions and actions where data is created and consumed. My test is simple: If connectivity to the cloud disappears, what stops working? That answer reveals whether you’ve designed a distributed architecture or simply stretched a centralized one across more locations. – Emma McGrattan, Actian
6. Design Connectivity Around Application Requirements
The design should be requirement-driven, starting with the application’s business criticality, expected throughput, latency tolerance and availability requirements. Those factors, not simply where the workload runs, should determine the connectivity, bandwidth and resilience an application needs. – Devendra Rajput, Accenture
7. Isolate Individual Workloads By Default
Drop the misguided and outdated belief that being inside the network, or on the same cluster, means being trusted. With modern virtualization technology, workload location and network segmentation between them say very little about risk. Apps on the same infrastructure often share more than a network link, so the blast radius isn’t defined solely by the network. Draw the boundary around each workload, block everything by default, and allow only what is needed. – Claude Mandy, Edera
8. Apply Data Security Wherever Work Happens
There is a broad assumption that achieving zero trust means routing every user, application and data flow through the cloud. But if our hybrid workforces have proven anything, it’s that this assumption is false. Rather than forcing every flow through the cloud and accepting the higher costs that come with it, enterprises must apply data security where work actually happens across offices, remote users, private applications, SaaS, cloud and AI environments. – Thyaga Vasudevan, Skyhigh Security
9. Design For Resilience, Not Just Connectivity
Retire the assumption that connectivity equals resilience. A network can be connected yet fragile when critical applications depend on distant services, congested routes or a single point of failure. Design around business-critical transactions, verified access and recoverability. The board does not buy connectivity. It buys confidence that the enterprise can keep operating when something breaks. – Kelvin Cheema
10. Place AI Inference Closer To Customers
Revisit the idea that one central region can serve everybody. It can’t. Serve Latin America from North American or European infrastructure, and latency kills you—and voice fails first. Then regulation hits, and the first thing a new AI rule asks is where the data sits. So, place inference where your customers are. Latency and residency: Design for both, up front. – Merlin Bise, Inbenta
11. Reconsider The Need For Corporate Networks
The concept of an enterprise WAN/LAN is outdated. The apps, services and computing required by a corporation are no longer hosted within a closed enterprise network. Security is now established at the application layer, not the physical network layer. But I still see enterprises managing private networks, spending millions on border protection and routers. The assumption that you need a corporate network needs to be revisited. – Siddhartha Rao, Oracle
12. Verify Physical Separation Between Network Paths
Don’t assume two carriers give you two independent network paths. Both connections may still run through the same conduit or building entry point. For critical cloud and edge workloads, trace the physical routes, look for shared failure points, and test failover. One construction accident could otherwise take out both the primary and backup links. – Nicholas Domnisch, EE Solutions
13. Assess End-To-End Workflow Performance
Reconsider the assumption that healthy connections mean a healthy business workflow. For example, agentic AI can send a single task across models, tools and data in cloud, edge and on-premises environments. Each connection may work well individually, yet the overall task becomes slow, costly or unreliable. Network design must account for the entire environment, including how those interactions combine to deliver a business outcome. – Casey Kindiger, Droma (formerly Grokstream)
14. Trace Application Delays Before Increasing Bandwidth
Revisit the assumption that more bandwidth fixes slow applications. A workflow making repeated, sequential calls between cloud and on-premises systems can spend most of its time waiting. Trace one complete transaction and count the round trips. Put tightly coupled work near its data before buying a bigger connection. – Nikhil Jathar, AvanSaber Technologies
15. Move Computation Closer To The Data
I would challenge the assumption that moving data is always easier than moving computation. As workloads spread across cloud and edge environments, repeatedly transferring large datasets can increase latency, cost and exposure. I believe network architecture should consider where processing happens, not just how systems connect. Sometimes the better design is to bring computation closer to the data. – Prajkta Waditwar, Box Inc.
16. Account For Where Decisions Happen
One assumption is that networks only transport data. With edge and generative AI increasing, networks are connecting complex intelligence models. Design must consider where decisions happen, how fast action must follow, industry type and cybersecurity protocols. Applications like autonomous driving need real-time decisions close to the sensor, whereas chatbot decisions can reside in the cloud. – Sachin Khanna, IQSIGHT
17. Plan For Traffic Spikes, Not Averages
Stop sizing networks around average traffic. AI inference, replication, backups and edge synchronization create short, extreme bursts that can overwhelm links even when monthly utilization looks healthy. Engineer for burst envelopes and priority classes so critical exchanges are protected when background traffic spikes. – Akhilesh Sharma, A3Logics Inc.
18. Match Workload Placement To Latency Tolerance
Revisit the assumption that every workload needs to run close to the user. A chat reply feels slow with an extra 100 milliseconds; a video generation job that takes a minute or two to render won’t be noticed. I’d sort AI workloads by how much delay users will tolerate and send the ones users are patient about wherever GPU capacity is available and cheapest. – Jerry Tang, Atlas Cloud
19. Make Network Policies Follow Moving Workloads
Businesses should revisit the assumption that a workload has one permanent home. Cost, performance, data and resilience may move workloads between the cloud, edge and on-premises environments. The network should make that movement seamless, with connectivity, access and security policies following the workload wherever it runs. – Alex Spokoiny, Check Point Software