Three Basic Models While each application will have its own I/O patterns and may require analysis with a protocol analyzer to completely understand, three basic client/server deployments generally determine what I/O you can expect. Applications that load executables and data from a server to a client create huge amounts of traffic. Moving the executable onto the remote workstation significantly reduces bandwidth needed. If this isn't possible this bandwidth-hogging app will be handled best by remote control. Examples are Microsoft Windows and Windows applications running from a server. Applications that store executables on the client and only need to load data from the server are in the middle of the bandwidth spectrum. This is common where files are accessed from a server with applications like FTP, e-mail and Web browsers. They generally work pretty well within remote access' bandwidth limitations. At the skinny end of the bandwidth needy are applications that load a client executable from a local hard drive and make a transactional transmission to a back-end server, which only returns the results of the transaction. This is the classic client/server model, and it's best suited for bandwidth-impaired remote node access. What's To Support? Once you've identified and understood the remote-access needs of your particular users and applications the next step is to determine the support they will require. Remote access systems fail for lots of reasons. That's the state of the technology today. Failures, and complaints, will occur. Support happens. The idea is to minimize it. You know the old saying, "Don't sweat the small stuff, because it's all small stuff." Well, in remote access the saying is, "Only sweat the support, because it's all support! Spending time up front understanding support cannot be overemphasized. Once a remote access solution is in place the cries for help will start flowing in. By then, it's too late to walk away. Understand how much support is needed, and how critical it is. Choose the methods that fit this need, and then evaluate the technologies based on how they meet your support profile. How Much? To figure out how much support you are going to need, look back at your list of user characteristics. At one end of the spectrum, users will share the same needs for applications and support, making for a large group. At the other end of the scale, user groupings will have no overlapping needs, making for a lot of small groups. For support to be successful it is important to make it the same for as many users as possible. The more needs that are shared the better. If your user groups appear to be many and diverse, push to combine and standardize needs. If this is not possible, work toward the ultimate in remote access support, let each user group support itself. While this may not be as cost effecti ve as centralized support, it may be the best you can do. It is significantly more work to centrally support multiple remote access approaches and may well be an exercise in futility. Complete control over a remote user's environment is impossible, and providing support remotely is difficult. Home desktop users will need a bulletproof install program to coexist with the unending number of software and hardware combinations that family-used machines acquire. Laptops, while in no way immune to creative software combinations, will probably be better known to you and can be evaluated and fixed in the shop. It is unlikely that many users will be able to fix their own problems. What's more likely to happen is that some technically challenged users will require support in greater proportion then either their number or their applications warrant. A beta test involving a cross section of the machines and key individuals can help determine what works and what doesn't. Before making remote access generally available take the time to work out as many of the "gotchas" as possible Say When Support will need to resolve some remote access failures quicker than others, and which need to be fixed quickly usually depends on the application. A quick way to test an application's importance is to ask whether or not a failure to connect can wait until the morning. If it can, you don't need to spend a lot of time building round the clock bulletproof support for it. A more methodical approach involves knowing the business or bottom-line impact of a failed connection for a particular application. In addition to looking for direct monetary impact, also look for deliverables that affect production schedules. Do not fall into the trap of thinking that a large number of users with similar needs must need around-the-clock immediate support. Focus instead on whether the applications in question need it. How Ya Do That? Centralized Vs. Distri buted - The Support Spectrum Designing remote access support really means deciding about control. A centralized support model provides more control than a distributed model. With centralized support, end users lose the flexibility to do as they please as the support organization takes on responsibility. With distributed, less controlled support, users give up unconditional hand holding for flexibility. There is no absolute right way. How you trade off control depends on your users and applications. Distribute To Avoid Support There are good reasons not to centralize remote access. Of course, from the support group's point of view it cuts down on the amount of work, but it really comes back to the users and applications. The most obvious reason for a distributed approach may be a small number of users. Are applications and security that localized to a single group? Is that group capable of it own support? Are the applications of little importance to the organization? (Be careful here. This is a touchy subject which may require discrete investigation.) If so, help the group choose and set up a desktop remote control system, make it clear that they are in charge, and then forget it. In some cases there may even be enough users to justify the whole "phone line, modem rack, central approach" thing, but the applications or users' reasons for remote access just aren't that important, and you know they never will be. This is outside the general trend, but it is possible. Carefully think through whether or not you want to be in the remote access support business. It may be better left to those that are using it. Moving remote access out into the hands of those using it really changes the role of the support group to that of technical consultants. Evaluation and recommendation rather than deployment and control become the primary responsibilities. Centralize to Control Support A centralized approach to remote access is popular beca use it scales well, supporting users and applications while getting the most mileage out of sharing phone lines, modems, remote access systems and support staff. Large numbers of nontechnical users often require hand holding, making a centralized, well trained help desk worth the expense. If in addition to a large number of users, the applications being used are business critical, it also makes sense to fold support into a production group like operations in order to insure "24 by seven by 365" support of not only users but the dial-up systems as well. Large number of users can have a momentum of their own that might be better handled from a central point of control. If your group has the know-how to support remote access, it may make support easier in the long run to drive a centralized support policy rather than having to pick up the pieces of multiple distributed attempts. While not a reason in and of itself, anticipated growth can sometimes be best handled through a centralized approach. Centralized Support Elements Controlling and supporting the client software is the single biggest ongoing task in remote access support. It is also the most underestimated. This is not necessarily because client software is bad. It's a result of having users all over the place, changing their PC's environment by adding or deleting software. It's a result of relying on the black magic of modems and the changing conditions of phone lines. It is not that the technology is new or poor but that the pieces are open to user changes. Supporting client software requires the following; A rock solid install program that is 100% percent compatible, no matter the combination of equipment and operating system. This means doing controlled releases of new versions of client software including performing regression testing of all previously functioning applications. Even though client software may have been tested by the vendor, it is necessary to test it in your environment. You also need clearly written documentation that is customized for your users. All of this takes incredible amounts of time, but not nearly as much as having to respond to and reissue thousands of copies of poorly tested client software. A centralized approach to remote access also means folding the support of the remote access servers, modems and phone lines into the operation's production environment. If you've decided on a centralized approach because of how important the applications running over remote access are, you will need the 24/7/365 that most operations group are geared up for. This will require the implementing technical group to provide design and support of all the pieces needed by the operators. The handoff of responsibility from the technical group to the operations group is handled through a production control procedure. Production control is the process in which operations anoints a new service as production and accepts responsibility for it. It is a pain to go through the red tape and finger pointing that is a part of production control, but it is the only way to provide rock-solid access to users (and sleep to the technical staff). You will need to provide thorough documentation and training to the operations staff. This needs to be in the form of a cook book, tested and signed off by operations management and lead personnel. It is important to think through the issues that have arisen during implementation and at which point technical support is to be called. This is an evolving document and relationship that will change and improve only on the basis of this formal relationship. The point is to remove personalities from the support equation in favor of procedures. It is also important to note that while operations will accept responsibility for round-the-clock monitoring of the remote access equipment, ongoing support will ultimately rest with the technical group. Besides this bittersweet relationship b etween technical and operations a couple of benefits arise out of a controlled central-site relationship. One is moving part the ongoing support expense from the technical development side of the house to an existing operational infrastructure and budget. The other is a creating a breeding ground for new entry-level technical expertise as well as a career path for operations. A help desk will provide consistent end user support and feedback. Because the help desk sits between the technical organization and the end user it is important that its workers are involved in the production control procedure along with operations. Help desk personnel are the best place to go for client software regression testing as they will have a much better idea of what problems users experience. Writing documentation and designing client implementations should involve the help desk because of its closeness to the user. A help desk is the first level extension of a technical group and should be expected to accept responsibility for the end product and share in its success. Next January 16, 1996 Print This Page E-mail this URL