Vendors and ASPs: Breaking the Ties That Bind

Over the weekend, we celebrated Independence Day. Ideals of freedom and breaking the ties that bind made me think of a few business-related ties that often bind a company. In the late ’70s, IBM still had a huge market share mostly because removing its systems from a company was difficult. Everything relied on them. Legacy systems became something from which companies sought independence.

Nowadays, ASPs and other Internet vendors provide critical services, making it hard to seek vendor independence when your business outgrows that vendor or, worse, if that vendor goes bankrupt.

Today, we’ll discuss several ways to work with outside vendors in ways that maintain your company’s independence and lessen your reliability on them.

The Contract

Most ASP and vendor contracts include some kind of escrow clause stating your company can have access to the code and software the vendor uses in the event it folds. Though this may feel like a safeguard against an impending loss of data or function, I’m not convinced it is.

Let’s face it, your company wouldn’t know how to install the software on the right types of computers, how to fix it when something went wrong, and how to keep it operating. Although an escrow clause doesn’t do any harm, the contract should have better safeguards in the event the company folds.

For example, there should be some secure feed directly from the ASP that allows backups of its internal data (as related to your company) on your end. For an email ASP provider, the XML feed would include the entire user list with preferences. By backing up this data, you can move on to a different vendor in the event the current one can no longer support your needs, your relationship suddenly ends, or the vendor goes bankrupt.

The Interface

I know a lot of ASPs link your Web sites into custom-branded versions of their sites. This is true for newsletter registration pages, help desks, mapping/driving direction pages, and so on. Though it’s extra work up front, minimize your reliance on the ASP’s servers. In an era of .NET and XML-based Web services, the ASP can provide the application’s back end while your company provides the front end.

This accomplishes many tasks. It allows designers and developers complete control over all aspects of a site (including the look and feel of the ASP’s offerings). It ensures a unified log-in for clients and customers, versus requiring them to log in separately to different areas of your site because they’re hosted by another company.

Most important, if the ASP folds or you decide to switch vendors, the user experience needn’t change. You own it on your servers. You could even develop the back-end functionality yourself and keep the front end looking the same.

ASPs and other vendors should provide core functionality your company doesn’t wish to spend time recreating, such as email serving, location-based mapping, help-desk maintenance, and traffic reporting. ASPs can also provide large-scale business services, such as online auctions and education centers. The front end of all these applications should be kept as close to home as possible. Applications should be capable of exporting information in a format that allows you to back up the data in the event your relationship with the vendor ends.

That way, you can always seek independence with impunity.

Until next time…


Join us at ClickZ’s upcoming AdForum and at Search Engine Strategies.

Nominate your favorite product or campaign from July 7 through close of business July 14.

Related reading