Are you ready to extend collaborative working to your remote workers?

Increasing numbers of workers are operating out of remote offices, and many will be working with a new generation of software. If your interest is in storage and in taking care of those remote workers, you are coming to a decision point.

The new collaborative software will enable many people to share thoughts on the same topic. This ought to be a good thing, and often will be (depending of course on the people involved). The promise of collaborative effort comes at a price, however, and part of the price of all that data and all those applications being shared will be increased demand for bandwidth.

Some of the up tick in demand will be because more people will be using the WAN to access data – it is after all the nature of collaborative efforts to share things, and for remote sites this means the WAN. Also however, companies will want their collaborative efforts secure, so some of the new bandwidth requirement comes as a result of adding security features to existing protocols (HTTP becoming HTTPS, for example).

It’s also a good bet that collaborative software is just the tip of the iceberg however, as many newer applications will rely on streaming content and will thus be bandwidth hogs as well. Whatever these applications happen to be, as they are deployed outside the central data center they are going to add increased demand levels on your remote sites’ abilities to handle WAN traffic.

Will your current wide-area file services (WAFS) be able to deal with this? Maybe yes, but perhaps not. Even those of you who have already installed WAFS at remote sites will find that traffic using these new applications has started to bog down again.

The issue is that generalized WAFS implementations will help with just about all WAN traffic, but optimizing (rather than just improving) specific applications for the WAN means modifying transmission protocols using modifications that are specific to each application. In other words, because you have speeded up Microsoft Word traffic may not count at all when you need to optimize for Lotus Notes. You want that kind of optimization? As likely as not, you’ll need specific code for it.

That being the case, it seems that a useful strategy when you know the sales reps are due to come knocking on your door selling WAN services would be to do the following:

Before any outsider arrives, check with the sales, service, support or other organizations outside the IT department to understand what software their remote workers are using now and are likely to be using over the next year or two.

Next, make a list of all applications that your remote sites are presently using, and another list of those applications they are likely to require over at least six quarters. If you have no idea about the specifics of the next generation apps your shop is going to be supporting, make a pass at itemizing the types of applications that are likely to be in place.

Finally, make sure any vendor supports your current needs, and also has a specific item on its roadmap showing the point at which they will add optimization code to support your next round of software applications. If they don’t optimize in favor of your applications, when push comes to shove you may not be able to maintain agreed-upon service levels.

Optimizing functionality and throughput should frequently be gating items, or decision points, when you consider new purchases. This surely should be one of those times.