A branch-based deployment model is ideal when a limited amount of bandwidth is available over the SNA-Server-to-host connection. In general, network traffic is greater between the client and SNA Server. If your organization has implemented a TCP/IP or other routable WAN protocol, then isolating the SNA traffic over specific connections that require host connections—in this case between the SNA Server and the host—will prevent unnecessary network traffic from being propagated over the WAN.
The branch model is also ideal for organizations that are migrating toward a single, routable WAN protocol solution, because it leverages existing investments in SNA data links. As you migrate towards an SNA-free WAN, you can tunnel SNA protocols (such as 802.2 and SDLC) from the branch office LANs to the central site LAN by deploying routers or Frame Relay Access Devices (FRADs) that support Data Link Switching (DLSw), frame relay (RFC 1490), or Asynchronous Transfer Mode (ATM) connections.
Because SNA Server computers are located physically near the clients that request host access services, local SNA Server administrators usually can manage users for their branch, responding more quickly to their needs. If necessary, however, SNA Server computers can be configured and managed remotely across your WAN links.
By deploying SNA Server in branch offices, you can take advantage of other applications designed to run on Windows NT Server. The branch-based server can assume a number of roles besides SNA Server functions, such as messaging server, database server, and web server. Components in the Microsoft BackOffice suite of server applications can work together to provide integrated groupware solutions for your users.