Building Scalable Remote Access by Mike Fratto  Understanding an Organization's Function Whether your network management is distributed or centralized has a big impact on how you learn what your users' needs are in each specific departments. Distributed staff work closely with users and they will have unique insights into users' needs and expectations. They will also be able to offer insights into future needs of the departments. By virtue of working inside of a department, distributed staff should have a clear understanding of the flow of information within the department and the information needs of general job functions. Centralized staff generally will have a more generic view of departmental needs, though their view will be more informed by the overall network structure of the organization. In either case, you'll have to talk to end users in departments to get a feel for what kinds of tasks they might perform over a remote-access link. Otherwise you're shooting in the dark. Every department and its users will have different remote-access needs and characteristics. For example: Sales People need to get information from many sources while out on the road. They might need to talk to manufacturing to get current capacity, to contracts to hammer out last-minute details, or access a groupware application to get e-mail, schedules and other information. Project Managers need to keep in contact with their departments to send and receive reports, handle problems and schedule events. Network Administration of the network from across the PSTN or the Internet has very serious security concerns. The transmission of passwords, even encrypted ones, is a potential security leak. On the other hand, network administrators have a higher access priority and shouldn't need to contend for ports. Branch Office Connections connect only when they need to, and so can reduce telecommunications costs substantially. These are automated connections or connections that are initiated on behalf of a user. Determining these and other needs should be the first step. A few generic questions to ask are: What are the most common tasks users will need to perform? Will they need access to e-mail? Database activity? File transfers? Network management? Will users need 24x7x365 access? Or just certain times of the day or week or month? Will users need access to all of their desktop/network applications and volumes? Will remote offices need to connect to other offices or to the main office? What are the unique needs of each department? Will users need access to servers and applications in other departments? Consider how the organization will benefit from having a set of employees on a remote-access system. For a sales f orce or a network administration department, the benefits are fairly clear. But for a department such as manufacturing or accounting, there might not be any need for remote access at all. Of course, your scenario will be unique, but if you don't do the legwork first to determine what you need, you will end up with a remote-access solution that won't fit your or your users' needs. A careful understanding of users' needs will determine to a large extent what kind of remote-access infrastructure you have to build. There are generally two categories of service that users will have to access over a remote link: Network Services cover basic communication needs such as network protocols, specialized middleware, network authentication, remote node and remote control. An importent element here is capacity planning (such as speed and number of modems), which is tied to the applications that will run across the link. The types of network services will determine what kind of asynchronous protocols needed, such as Point-to-Point Protocol, ARA, NRN, and what network stacks you will run, such as IP, or IPX, for example. Application Services cover what applications users will run over the remote-access link. Some of the elements to consider here are whether the current departmental applications will run adequately over a slow link. Custom-built applications and some standalone ones are very slow because they transfer lots of data across the link while others require little more from the network than file transfer. This is akin to the thin/thick client debate. The specific issue with remote access is the amount of data that is transmitted across the link while running a client-the less the better. Understanding your organization's needs will ease the transition to an enterprisewide remote-access solution because you'll be better prepared to find solutions to fit those needs. Some network applications can run seamlessly on top of any network protocol, while others require special handling. Lay down the requirements that your remote-access solution must meet to be successful. This process highlights previously hidden issues such as levels of access required per user group and special security measures needed. Like other network planning, the business goals should drive the technology planning. Not every department will need remote access, nor will every department need the same level of remote access. Updated January 17, 1997 Print This Page E-mail this URL