InformationWeek

In selecting an ASP, your first concern should be security. If you're going to trust someone to handle your financial, ERP, and customer-relationship management applications, you'd better make sure your data is in good hands. The ASP you choose should have a security officer, a written set of policies, and regular security audits-and all audit results should be available for your inspection.

Some ASPs go so far as to do background checks on their staff members who will have access to your data. Your ASP should be checking on you, too: Upon receiving a request for new users to access sensitive data, the ASP should contact your staff to verify the request.

Along with physical security and using technology such as virtual private networks, firewalls, and intrusion-detection software, ASPs must provide safeguards to ensure that each client sees only its own data. At present, virtually all ASPs do this by setting up each client with its own set of hardware to run provided applications; the hardware most often is housed in the co-location facilities of a top-rung hosting facility. Hosting providers are generally quite proud of their facilities. You'll know if you're dealing with one of the good ones: They almost always insist on taking you on a tour of their facilities if you're near them. Be prepared to "ooh" and "ah" over rooms full of batteries and generators housed in bunkers.

To provide more aggressively priced services, ASPs will seek to host numerous clients on the same server hardware. Particularly in a shared-hardware environment, be sure that your data is safe from prying eyes. Companies such as Oracle, which is working on a technology to create virtual databases within a single instance of its software, are enabling their applications to support this type of configuration. Make sure your ASP is using software that explicitly supports different organizations if shared hardware is to be used.

Accessing your applications will require bandwidth. Depending on whether your ASP uses a fat- or thin-client model, the parameters of your connection will be crucial. Fat-client software is often unforgiving, particularly in terms of end-to-end latency. For this reason and others, you should opt for a thin-client model. If you do require the full fat-client software, you may find your provisioning costs going up, potentially requiring leased lines rather than VPN connections.

Even for thin-client deployments, expect to set up a new Internet connection that will be dedicated to accessing your leased applications. This line should come from a service provider that also supplies lines into your ASP's co-location facility. Any other configuration will undoubtedly result in finger-pointing if you experience poor application performance. Most ASPs will specify the Internet service provider. We were surprised to see that many are specifying VPNs via digital subscriber line services. That's quite a testimony to the perceived business viability of DSL.

At this point, choosing multiple best-of-breed ASPs for various applications is a bad idea. Just as with in-house deployment, the idea is to use no more than a few sets of data to feed a number of applications that will then propel your business to unimagined success. However, a best-of-breed approach likely means replicating data across several ASPs; this all but precludes integration between applications unless that task is handled in-house. As you'll recall, part of the point of this whole exercise is to get those functions off your IT staff's back.