The Top 10 Remote Access Mistakes

Companies with multiple locations or remote users frequently need to connect computer networks between them. Done right, those networks can significantly improve business performance and reduce costs. Done wrong… well, let’s not go there.

What are some of the common mistakes? Hubris. Lack of planning. Lack of testing. Lack of perspective/familiarity. Misjudging your risk exposure. Read on...

1. Buying too much bandwidth (speed).

Many companies are paying far more than they should for wide area communications because they haven't measured actual requirements, or have implemented inappropriate solutions. Knowing where to measure is as important as knowing what.

2. Using a network method that conflicts with the software.

Software that was written for office networks is often dog-slow on interoffice networks, no matter how much expensive bandwidth you feed it. The right solution may be to change either the software or the network, or it may just be to find the right way to make them work together.

3. Assuming Thin Client/Server Based computing is like any other method.

It's not. The paradigms are different, they're subtle, and it takes time to understand how. Training and experience can make a huge difference. Or... well, you could get lucky. Know your risk.

4. Not talking to the application software provider.

Some software, even client/server applications, may behave unexpectedly in server-based or wide area environments. The vendor may have no idea what should be done, or may have key insights. Ask.

5. Assuming Server Based computing is only for remote access.

Some very large companies have saved massive amounts of money by going completely server-based. It can dramatically reduce both support and hardware costs, not to mention improving corporate flexibility. Overnight corporate software upgrades become a reality, and are an experience to be savoured.

6. Thinking all methods are the same.

There are many different remote access and server-based computing solutions, which differ sometimes surprising ways. When choosing the best approach, it's vitally important that you have a firm grasp of your priorities, so you can determine which features are important to you.

7. Not allowing for growth.

One of the major strengths of server-based computing is its ability to scale will corporate growth. That doesn't happen all but itself. It requires forethought. If you're sure your company won't grow… well, maybe you're right.

8. Using the wrong hardware.

Servers that support thin clients have distinct hardware requirements – an interesting mix of traditional server and workstations, but different from either. Come to think of it, that applies to the software requirements, too.

9. Mixing server functions.

A terminal server is not a file server, or a directory server, or data base server, or a web server. You can force it to try, and it will probably work, sort of. Don't expect your users to stay happy for long.

10. Delivering the pilot project to the customer.

Pilot projects are famous for unreliability and “undocumented features”. As Frederic P. Brooks said in “The Mythical Man-Month”, the question isn't whether you will build one; it's who will learn from it or be stuck using it.

And a bonus one:

11. Not getting the help you need when you need it.

Be clear on your risk. A low profile project can still set big precedents, and a high profile project can take a swan dive into a gopher hole. Alan Kay said, “Perspective is worth 30 points of I.Q.” Many times, all that's needed is a bit of perspective.

Is that all there is? Of course not. But these should give you an idea of the kind of things to watch out for. Clearly, interoffice networks are an area where experience counts, and there’s more than one way to get it.