Client/Server Remote Access Solutions by Bruce Boardman Scope of This Article Hundreds of products provide remote access service of one kind or another. We are going to focus on the single largest segment of remote access, devices that support individual clients dialing over switched analog lines to centralized LAN-based servers. Client/Server Switched Analog Remote Access is the most accurate description but for brevity we will simply say "remote access." "Remote Control" and "Remote Node" Defined Remote access usually is divided into two main categories: remote control and remote node. Remote control occurs when the remote user "takes over the keyboard" of a computer on the LAN. Applications are processed on the LAN-based computer. The only traffic going to the remote PC is the screen and keyboard input/output. Remote node access, on the other hand, connects the remote computer to the LAN as if it were a node on the LAN. This means that all the traffic that would go to a LAN-based computer goes to the remote computer. This difference has various consequences for remote use, as we will discuss below. First Design Support, Then Buy Technology A remote access system is made up of several technologies--clients, servers, modems, phone lines--a long chain connecting remote users to the corporate LAN. None of the links in the technology chain are overwhelming in their "rocket science", but none are so easy that it's a "no brainier" to choose and implement the right one for you. Perhaps the most overlooked part of remote access is the time and structure needed to support it. Like no other system, remote access can eat hours if not planned for. It is not a server in a closet that "just works." It is a tether of technology that binds users to the LAN, a connection that in their mind is just as reliable as what's at their desk in the office. It is a rope of technology in which there is just enough slack to hang yourself. When considering remote access, and trying to decide which approach is the right one, take some time up front for planning. Step back and get a picture of what is driving the need for remote access in your organization. Understand what makes users unique and what they share. Get a handle on the amount of support their needs are going to require. Once the reasons for remote access and the implied support are understood, you can find a solution whose technology will meet the needs without burying you in support tasks. Make a List The fist step is to find out which users and applications need remote access. Keep in mind that you are building a support strategy and picking the right technology, but don't feel constrained yet. The idea is to get an idea. Let's start with the users. The Users Understanding the kinds of users, how they are grouped and where they will be dialing from are the key ingredients. Look at the grouping and number of users that need to be supported. The question is whether small groups that need different applications exist or whether the small groups really make up a large group needing the same set of applications. If the groups are segregated, separate departmental remote access solutions may make more sense. If, on the other hand, a single large group or a number of smaller groups need the same resources, a solution that will scale and lend itself to centralized control and support is the one to choose. Where users are calling from is important, too. If the remote access is initiated from a stationary location like a home, installs and upgrades need to be bulletproof, because they are likely to be done by the users. If, on the other hand, roaming laptops are in the picture, installation can be performed and tested by your technical organization in the safety of a lab or helpdesk. Take a look at the kinds of users. Are they technical or non-technical? Technical users are less likely to need hand-holding support but are going to demand the most from the remote access system in terms of flexibility and access. The non-technical user will need the most support, in terms of setup and ongoing stability. The non-technical user, if not planned for, is a real resource drain and the surest way to get a remote-access black eye. Are the users Big Cheese or Joe Cheese? While the Big Cheese is often a reason for exaggerated attention, this is often handled individually and does warrant a full-blown helpdesk and 24-hour, seven days a week support. Joe Cheese, on the other hand, does not mean that the support is of little importance. The only way to tell is to look at the business deliverables created with the applications used. The Applications The applications destined for remote access will provide clues about the importance of remote acces s to the organization as well as about which is the right technology to deploy. Importance is determined by looking at the deliverables produced with an application. The kind of input/output (I/O) that an application generates between the client and server will fit into either a remote control model, a remote node model, or some mix of the two. The first thing to do is to list all the applications that are likely to be run over remote access. Some examples might be e-mail, file transfer, Web browser, database access, or terminal access to a timesharing or mainframe system. Reasons for the access might include desktop file access, sales placement, keeping in touch while on the road, or support of a production data processing system. Spread the applications and reasons out on the kitchen table and begin to analyze them for business significance and I/O characteristics. Determining how important an application is requires asking what kind of bottom-line impact it has, and what new paradigms it will create. Applications such as access to desktops from home, file transfer, sales placement and invoice tracking have fairly obvious value. Surfing the net for research or delivering a proposal by e-mail may not. Sometimes, an application does not have an obvious bottom-line impact, but it's still widely popular. This causes a dilemma: because of its popularity, it will require a lot of support, but not supporting it will release a tide of political discontent from the user community. Fortunately, leverage to justify such support should be available from the divisions and departments most likely to voice discontent. The trick is to get in front of the tide and ask the noisy to put their money where their mouth is. It may even be an opportunity to build support for other more necessary applications. New organizational paradigms can be achieved with remote access. Your organization may be trying to reduce commuting to comply with federal guidelines or trying t o populate new geographical regions without spending much on plant and equipment. Look for ways the work force can be more responsive to the customer, such as by providing on-site invoice tracking. Look for flexibility, such as being able to meet a deadline even when a key participant is on the road. Look for opportunities to provide benefits to workers, such as working at home or providing flex time, which many may perceive as allowing work to get done while still "having a life." Application Input/Output The next step in sorting through the applications destined for remote access is to look at their I/O. The bandwidth available in a switched remote access connection is small and must be used conservatively. How applications use that bandwidth differs. Picking the right remote access technology depends on understanding how this tiny resource will be used. Many LAN-based applications assume the availability of several megabits per second of bandwidth. The switched WAN links that remote access uses provide 115.2 kilobits per second at best, even with fully compressed data and a V.34 modem. This more than tenfold difference matters less with a remote control design than with a remote node approach, but there is no way around the fact that WAN links are much slower than LANs. Next May 1, 1996 Print This Page E-mail this URL