By Tim Landgrave
In late July, SprintPCS announced plans to deploy a nationwide network of 802.11b hotspots that would exceed 2100 locations. Where TMobile has focused on consumer locations (including coffee shops like Starbucks), the SprintPCS strategy is to encourage a more rapid build out of commercial locations like hotels, airports, and business centers. Although its existing billing systems will not combine its 50K to 70K wireless CDMA services (PCS Vision) and its new 11-MB wireless Wi-Fi services initially, industry analysts expect to see combined plans emerge in early 2004 focused on corporate users who are part of a distributed workforce.
These workers spend more than 50 percent of their work hours outside of their offices and need to have some level of access to corporate systems to get their work done. With Sprint and TMobile already offering these services and cable and DSL modem installations on the rise, CIOs need to begin taking a serious look at how they’ll accommodate the rising tide of distributed workers. I’ll look at the productivity, technical, and legal issues surrounding the creation of corporate policies that provide remote system access.
One of the most important issues that you’ll have to face when devising a remote system access policy is whether the access is preferred or necessary. As more companies begin relying on e-mail as a primary communication mechanism (even more than the telephone in many cases), you can certainly argue that remote access to e-mail and scheduling systems is becoming mandatory. In some cases, however, using offline copies of e-mail and schedules is “real enough time” and the additional cost to configure, support, and secure external access to collaboration systems isn’t justified.
Beyond the e-mail and scheduling issues lie the issues of access to corporate systems. Most companies have found that giving some level of access to operational systems (sales order and purchase order systems, for example) for both employees and external partners can make financial sense from a productivity standpoint. Why should the remote sales person write the order on a piece of paper and then fax or re-key the order later if there’s a way to enter the order online?
As faster, more reliable, and more geographically available remote connectivity options become available, these systems become more practical to deploy remotely. Few companies have found a reason to allow remote access to their core financial systems. The risk is generally not worth the potential reward.
As communication protocols and standards become more integrated with core operating systems, the cost of installing, supporting, and maintaining remote access continues to decline. Virtually all e-mail systems provide some kind of HTTP(S) access, allowing corporations to give any employee access to their e-mail and scheduling system over any commercially available Internet pipe. These systems are ideal for distributed workers because they can use fat 802.11 pipes to send and receive not only simple e-mail, but also large attachments. But using HTTP e-mail doesn’t solve the problem of synchronizing a local machine’s mail and calendar data with the central mail server.
In most cases, e-mail synchronization or any kind of non-HTTP access to your company’s systems will require a more secure connection. Where this required expensive hardware and support-intensive configuration in the past, most modern operating systems already include support for VPNs using either PPTP or IPSec to secure the remote channel. And most remote connections (including those provided by Sprint, TMobile, and home network routers) support hosting the VPN on that connection. By providing VPN access to key distributed users on high-speed connections, you can give the remote user an experience very close to that of a local connection.
I used the term “in most cases” here because technologies are coming that allow more secure access mechanisms to ride on top of existing HTTP plumbing. For example, Microsoft has released its first RPC over HTTP provider for Exchange 2003 that will be supported by the upcoming Outlook 2003 release. This will allow Outlook 2003 users to fully synchronize with an Exchange 2003 server but require that the company open only the ports allowed for HTTP (80) and SSL (443) access. Other companies are releasing Web services-based solutions that use a similar mechanism to transfer encrypted information between their application and the application client.
Unfortunately, now that remote access to corporate systems is becoming more commonplace, you also have to consider the legal issues surrounding their use. For some companies, this means amending their existing corporate policies to include provisions describing allowed and disallowed practices when using their systems remotely. For example, although companies may allow Web users to save passwords in the browser cache when used locally, they certainly don’t want workers to do so when using the system on a remote machine—even a home PC. You must also consider labor law issues that you may not even be thinking of right now.
For example, I worked recently with a Fortune 500 company whose lawyers told it that it couldn't allow hourly workers to access any of the company’s systems remotely. These included e-mail, ordering systems, and the intranet site. Why? Because doing so would open the company up to an individual claim or a class action lawsuit by disgruntled hourly employees who could maintain they worked hours that were not paid during the time they accessed the system remotely. Ultimately, the company chose to make an investment in the integration necessary to allow employees designated as hourly to be refused remote access. But the hourly employees still don’t understand why they’re being "singled out" and having their access taken away even though the legal issues have been explained to them.
Is it worth the headaches?
In almost every conversation I have with a senior executive who’s convinced that he and his key employees need remote system access, it comes down to this question, “Is it worth the headaches?” I generally try to take the question and put it in simpler, more financial terms. The question should be restated as, "Will the productivity and agility you gain by being able to access your systems remotely outweigh the costs (including not only setup but ongoing support costs)?" At some level (for example, remote e-mail access) the answer is "yes" and at a higher level (complete VPN access to the system) the answer turns into a "no." The challenge going forward is to be able to balance the level of service provided (and expected) with the cost of installing, supporting, and maintaining remote access to your company’s corporate systems.