Most enterprises are making architectural decisions for the branch they have today. The smarter ones are planning for the branch they will have in three years.

That distinction matters more than it might appear. The branch is changing, not incrementally, but fundamentally. AI workloads are moving to the edge. IoT is proliferating faster than endpoint agents can manage. Return-to-office pressure is turning lightweight field sites into mini-campuses. The branch is no longer just a consumer of cloud services. Increasingly, it is becoming a producer of compute and intelligence.

Against that backdrop, Mauricio Sanchez's three-part café networking series in SDxCentral – Part 1, Part 2, Part 3 – arrives at exactly the right moment and asks exactly the right question: how much branch infrastructure can enterprises simplify without sacrificing security or operational effectiveness?

The 30/60/90-day roadmap, the governance discipline around exception registers and kill dates, and the multi-year scaling blueprint create a clean, rigorous framework. The market data supporting it is real: Dell'Oro projects secure access service edge (SASE) revenue approaching $21 billion by 2030 while access router revenue shrinks to under $1 billion. The direction of travel is not in dispute. Café networking is not wrong; it is a valuable operating pattern for the right branch. The risk is mistaking that pattern for the whole enterprise branch estate.

What deserves more discussion is not whether café networking works. It does. The more important question is where it works, where it begins to weaken, and what happens when the branch you're designing for today becomes something else entirely.

Where café networking works well

For a well-defined class of enterprise sites – pop-up retail, temporary clinics, small field offices, and lightweight branches where software-as-a-service (SaaS)-first access is the primary workload – café networking is the right design. Proxy-first. Minimal on-premises hardware. Identity and device posture as the control plane. Cloud inspection as the enforcement layer. No default enterprise network extension.

Sites are stood up faster without private IP ranges and virtual LAN (VLAN) dependencies, while the blast radius of a compromise is contained by default. The series' insistence on governing SD-WAN tunnels as time-boxed exceptions rather than default infrastructure is exactly the right instinct: simplification requires discipline to hold.

The governance model in Part 2 is particularly strong. Treating every non-proxy flow as an exception that requires an owner, a reason, and a kill date creates operational accountability that most enterprise WAN programs lack. That discipline applies well beyond café networking environments.

Where the enterprise picture gets more complex

The challenge is that most enterprise branches are not café-like. They are not usually simply places where managed users connect over the internet to SaaS applications. A retail kiosk and a regional manufacturing facility both carry the label "branch," but they share almost nothing operationally.

Return-to-office momentum is driving more users, devices, and workloads onto branch infrastructure that was not designed for the load. These environments host VoIP, point-of-sale systems, IoT cameras, operational technology, APIs, and employee-owned devices. They depend on east-west traffic flows that don't route naturally through a cloud proxy, and they carry deterministic performance requirements that best-effort internet cannot reliably satisfy. In other words, café networking is strongest in user-to-cloud environments; many enterprise branches increasingly involve user-to-app, device-to-device, machine-to-machine, and app-to-app flows. That shift has consequences on three fronts in particular, namely performance, security, and the emerging AI workload, each of which the proxy-first model handles less completely than it handles SaaS access.

The blog series does not ignore this. Part 3 makes the point that large campuses are a poor fit for a pure proxy-first model; it lays out a campus sequence: segmentation first, then proxy-first wherever feasible, with WLAN and switching handling local segments, and SD-WAN reserved for the cases where local or media characteristics genuinely demand it. That is a thoughtful design, and it deserves engagement rather than restatement. The disagreement is narrower and more specific. The series treats local enforcement and routed connectivity as a time-boxed exception to be governed and ultimately retired. For a large class of enterprise branches, that local enforcement is not a temporary bridge at all. It is the permanent, load-bearing default.

Connectivity is not the same as performance

There is a second dimension the café conversation tends to leave implicit. The café model is, at its core, an architecture for the access and policy control plane: identity decides who connects, device posture decides on what terms, and cloud inspection enforces policy. What it largely assumes away is the performance plane: treating any broadband or 5G link as adequate commodity transport. For a SaaS-first microsite, that assumption holds comfortably. For a branch running VoIP, telehealth, point-of-sale, video, or other real-time and transactional workloads, it does not. These applications are unforgiving of latency, jitter, and packet loss, and a single best-effort link cannot reliably deliver against their requirements, least of all when backups, streaming, and software updates are contending for the same last mile.

Meeting those requirements is an engineering problem, not a connectivity problem. It calls for multiple active WAN paths – MPLS, broadband, LTE/5G, satellite – with application-aware steering that selects among them in real time against measured latency, jitter, and loss; sub-second failover; loss-mitigation techniques such as forward error correction and packet duplication; and quality of service that protects business-critical traffic even when it is encrypted.

None of that capability lives in a cloud proxy. It lives in the WAN fabric at the branch, and routing every flow through a distant inspection point can compound the very path variability these applications cannot absorb. The café conversation is rigorous about where policy is enforced. It is comparatively quiet about whether the underlying path can carry what a given branch actually runs: and for a meaningful share of branches, that question is the one that determines whether the site works.

The AI branch changes the equation

There is a larger shift underway that the café networking conversation has not yet fully absorbed: More enterprise branches are becoming compute nodes.

AI inference, analytics, and edge intelligence are already moving to retail locations, factories, health care facilities, and distribution environments, driven by latency, sovereignty, and operational requirements that centralized cloud inspection was not designed to meet. AI workloads generate machine-to-machine traffic, localized east-west flows, and latency requirements that cloud-proxy round trips cannot satisfy. AI at the branch also introduces attack surfaces, like model integrity, data exfiltration pathways, and agent action verification that cloud-only security architectures were not built to address.

Not every branch will host local AI inference in the next planning horizon. But enough will that this trajectory is worth incorporating into architectural decisions now, before the exceptions accumulate.

The real work is making both models operable at scale

The café networking model asks the right question: how much branch infrastructure can enterprises simplify without sacrificing security or operational effectiveness? For microsites and low-complexity branches, the answer is quite a lot, and the series provides an excellent framework for getting there.

For branches with significant IoT, OT, real-time application requirements, local application dependencies, or emerging AI workloads, the café model requires augmentation rather than wholesale adoption. The architecture needs intelligent traffic steering across multiple WAN paths, local enforcement that does not depend on a cloud-proxy round trip, segmentation across users and unmanaged devices, and security visibility that extends consistently across users, devices, applications, and workloads regardless of where those workloads run.

Most enterprises operate multiple branch types simultaneously: retail locations, campuses, clinics, factories, remote offices, and increasingly AI-enabled edge environments. The operational challenge is not choosing one model. It is governing café-style simplicity and richer branch networking consistently across a distributed and heterogeneous footprint.

The future enterprise branch will not be defined by stripping capability from the edge. It will be defined by making sophisticated networking and security dramatically simpler to deploy, govern, and operate at scale across the full spectrum of what modern branches actually require.

Sanchez's series gives the industry a clear and rigorous frame for one important end of that spectrum. The next conversation is about mapping the rest: the branches that need SD-WAN, SD-LAN, local segmentation, cloud-delivered security, and AI-era enforcement to work together under one operating model, including the security controls that belong inside the branch, not only above it, where headless IoT and OT devices live outside the proxy's reach and a flat LAN remains a free-movement zone. I hope this is a useful contribution to that discussion.