Tuesday, October 20, 2009

Towards a Successful ASP Agreement, Pt. 2

Where Has All My Data Gone?

Microsoft and T Mobile are currently receiving lots of bad press relating to the loss of data from users of T Mobile's Sidekick device. Because Microsoft was essentially acting as an ASP for those users – storing data for them – this event raises some interesting questions.

What happens if my ASP loses my data?

That depends on whether the data is critical to the operation of your business. If you were using thousands of Sidekicks to run a world-wide enterprise, you would probably be out of business. In a more likely scenario, if you had out-sourced complex calculations or processing of a large volume of information, you might still face a serious business interruption. Orders may not be filled correctly, or on time, trading (or reporting) deadlines might slip past or payroll checks might not issue on time.

Of course “What happens if my data is lost?” is the obvious question. A better one is “What is the appropriate response to such a loss?” While the answer is obvious – restore the data – it begs a number of questions:

Who is responsible for the restoration?
Who will pay the cost?
Where will the information for the restoration come from?

According to media reports, in the Sidekick case both the main and backup databases were lost due to a server malfunction. From that it would appear Microsoft observed one of the main commandments of computing: Back up your data. Whether the back ups were made in an appropriate manner is not clear from published reports. For example, were the main and back up files stored on the same server, meaning that one failure would interrupt access to both?

User difficulties were apparently compounded by the fact they did not have copies of their data on their PCs or their Sidekick devices. They could not simply update Sidekick from PC (or vice versa) and continue with their lives while Microsoft and T Mobile sorted things out. They had put “all their eggs in one basket,” and lost the basket.

The lessons are not new:

Back up your data
Observe appropriate back up protocols (e.g. off-site storage of back up data)
Keep your own copies, just in case

What safeguards should I observe?

The first safeguard has just been mentioned – keep your own copies. The second is to require the provider to keep its own back ups, and to observe appropriate processes and protocols. At a minimum the contract should require back ups, and specify the protocols to be observed. Failure of provider to meet these obligations should be defined as a material breach of the agreement, constituting grounds for subscriber to terminate the contract. But mere words on the page may be insufficient, particularly if the data is critical, sensitive or protected by law. After all, the ink on the page will not rise up and compel provider to perform. Even a court order enforcing the written words might come only after significant, if not irreparable, harm, has been done to your business. The more important the information is to your business, therefore, the more important it is to verify provider's data protection practices before the contract is signed, and to inspect provider's facility periodically to ensure compliance during the contract term. To avoid any doubt or dispute on the question, the right to inspect should be written into the agreement.

Yet the ASP model contains an exposure not presented by the Sidekick occurrence – loss of functionality. Users could still access the various functions of their devices, but could not retrieve their stored data. But what if the software that enabled each device to communicate with the servers had failed? What if software used by your payroll processor abruptly doubles everyone's salary?

Mitigating this exposure in the ASP context requires a bit of care. Should subscribers require their providers to have off-site back up facilities, able to begin processing in the event a disaster strikes the primary site? Absolutely, if the provider is providing services critical to subscriber's business. Again, the need for careful drafting by counsel and due diligence by business personnel rises in direct proportion to the importance of the services. If provider cannot, or will not, provide such a mirror back up site, consider creating one of your own, complete with copies of the necessary software, licensed for use in the event of catastrophic failure by provider. (Care would also be needed to define what constitutes a “catastrophic failure”.) But if subscriber is compelled to create its own emergency back up site, is the ASP investment cost effective?

What are my remedies?

“What are my remedies?” is simply a polite way of asking “What does my provider owe me?” Assuming the contract has been properly researched, drafted and enforced, the answer should be “Nothing.” A failure at provider's facilities should pass virtually unnoticed by subscriber, certainly without loss of critical information or functionality. That would be an excellent example of a contract that works. After all, even if a court eventually orders provider to hand over a sack of money equal to the value of the interrupted services, it may be too little and too late to pay for your attorneys, lost business and loss of goodwill.

COMING SOON: Part 3 - When is a warranty of 99.7% availability a bad deal?

Wednesday, October 7, 2009

Steps Towards a Successful ASP, Part 1

The Application Service Provider ("ASP") model has many attractions:

  • Someone else pays for the hardware, software, maintenance, updates, etc.
  • Subscriber pays a fraction of the total cost of implementation.
  • Competition gives each provider an incentive to continually improve their offerings.
But there are also potential down sides. Someone else controls the:
  • Hardware
  • Software
  • Personnel
  • Security
  • Back up
  • Disaster recovery
If your ASP crashes, will it take along your critical processes?

Setting aside the worst case, there are other reasons an ASP may be unsuitable.
  • A third part will be given access to subscriber's data.
  • The services offered may not precisely meet subscriber's business needs or processes. Because many ASP business models are based on standardization and volume, provider may be unwilling to offer custom solutions for individual subscribers. In that event, is it cost effective for subscriber to revise its policies and practices to accommodate the proposed application?
  • Provider, not subscriber, controls when and how changes to the application are made. If changes effect the "look and feel" of the application, subscriber may encounter unexpected costs and delays for re-training personnel. Alternatively, subscriber may not want the added features, and extra cost, of Version X +1, while provider may not want to continue to support Version X.
  • In general, neither provider nor subscriber controls the transmission lines, creating an exposure - interruption - that neither party can fully control.
  • Quitting a provider can be problematic. For example, will the provider simply block subscriber's access to the application or provide transition assistance. If assistance is provided, what will it cost?
Some of these concerns can be addressed through careful contracting, some cannot. If granting provider access to subscriber's data violates privacy laws, or if provider's business model does not allow for needed customization, no amount of brilliant lawyering will make the deal work.

What then, are the foundations of a successful ASP project? A full answer would require a book (See shamless plug below), but I can address some highlights here.

1. Due Diligence

As mentioned, if provider's offerings do not meet subscriber's needs, the relationship will be rocky, at best. But diligence must extend beyond matching needs to services.
  • Is provider financially sound?
  • Are its personnel adequately trained?
  • Does vendor have all the necessary permits and licenses?
  • Does vendor implement appropriate physical and logical security?
  • Are appropriate disaster recovery measures in place?
It is important that subscriber verify this information before signing the contract. Afterwards, one can always sue if, for example, there is a disaster and provider does not have in place the recovery safeguards required by the contract. Subscriber might well recover money damages, but those will be cold comfort if he/she has been put out of business.

2. Interim Remedies

In fiction, at least, the appropriate response to any business disagreement appears to be "So Sue Me!" A better approach might be to build in "safety valves" to permit discrete disagreements to be resolved without derailing the entire project. Examples would be meet and confer requirements, permission to withhold payment of disputed balances and a narrow list of circumstances in which provider may suspend or terminate services.

3. Objective Standards

When will the application be available?
What processing speeds will be provided?
What response times will be accepted?
In what format will subscriber's data be stored?
In what format will reports and other output be delivered to subscriber?

To protect both sides, it is important that these and other standards be stated clearly and be subject to objective measurement. Without objective standards, subjective judgments ("It's too slow!") could put the project at risk.

4. Testing

We will purchase an auto after a 20 minute test drive and a house after a walk-through and home inspection (and a little haggling). Outsourcing business functions, however, merits more detailed examination. The more critical the processes, the more important it is to thoroughly test the application in the most realistic setting possible.

5. Business Continuity

If the provider's servers fail, will subscriber's business come to halt? Thus the need to verify that provider observes proper security, back up and recovery procedures. For truly critical processes, consider requiring a source code escrow (which must be kept current) or maintenance of a mirror site that could easily be taken over by subscriber.

We will explore these and other features of a successful ASP contract in greater detail in future postings.

This article is derived from "Application Service Provider and Software As A Service Agreements Line by Line," Kelly L. Frey, Sr. and Thomas J. Hall. Published by Aspatore Press, 2007.

Note - my friend and colleague Kelly Frey had no part in drafting this post. Any errors in it are mine alone.

Thursday, October 1, 2009

He's Back

After a summer of medical challenges, I am once again able to sit up at the keyboard and string two thoughts together.

Sorry for my long silence.

Now let's all get back to work designing Contracts That Work.


"B" Is For Boilerplate

Lawyers are fond of boilerplate language. It is quick to add, it covers a wide variety of exposures that might otherwise be overlooked and, since many of the phrases have been around for ages, the meaning is not likely to be debated. It is quick, it is easy, but it can also miss the mark.

Non-lawyers are now asking "What is boilerplate?" It is a lawyer-speak for language that is considered more or less standard in all contracts, such as a disclaimer of consequential damages: "Vendor hereby expressly disclaims any and all liability for consequential damages, whether or not foreseeable and whether or not Vendor was advised of the possibility of such damages." Boilerplate is generally found under the heading of "Miscellaneous."

Difficulties arise, however, when boilerplate is cut and pasted without regard for the transaction in question. For instance, this language comes from an agreement for custom programming service:

Each party to this Agreement shall keep in force during the term of this Agreement a policy or policies of insurance providing the following coverages in commercially reasonable amounts from reputable underwriters:...comprehensive automobile liability, covering all owned, hired, and nonowned vehicles of a party or its affiliates.

Setting aside the questions of what are "commercially reasonable amounts" and how to identify a "reputable underwriter," I am still wondering why auto insurance is relevant to this deal. If memory serves, customer and vendor met twice - when customer drove to vendor's offices. That would not create an exposure for vendor. After the work was awarded, all communications were via telephone, Web conference and email. I struck the language (and vendor agreed) because I saw no raise questions as to whether customer was carrying insurance that would contribute nothing to the deal.

Two of my favorite bits of boilerplate:

1. Mask Works

"Vendor claims all right, title and interest in and to, works of authorship, inventions, mask works, discoveries and other intellectual property created in the performance of this Agreement." But what is a mask work?

According to Wikipedia, a mask work is:

A mask work is a two or three-dimensional layout or topography of an integrated circuit (IC or "chip"), i.e. the arrangement on a chip of semiconductor devices such as transistors and passive electronic components such as resistors and interconnections. By extension, it also refers to the copyright-like intellectual property right conferring time-limited exclusivity to reproduction of a particular layout. The layout is called a mask work because, in photolithographic processes, the multiple etched layers within actual ICs are each created using a mask, called the photomask, to permit or block the light at specific locations, sometimes for hundreds of chips on a wafer simultaneously.

Clearly a mask work can be quite valuable, and such works are specifically protected by US law (17 USC Section 904). At the same time, mentioning mask works in a contract for custom database design merely invites question and confusion, without adding to the protections given to either party.

2. All Rights Anywhere In The Known Universe

"Licensor hereby retains all right, title and interest in and to the intellectual property anywhere in the known universe."

Yes, I have seen this language in genuine contracts. I generally reply that, to my knowledge, the Martians have not agreed to recognize American patents and copyrights. According to one of my very senior colleagues, this language started in a New York firm when satellite communications started to become common. The reasoning was that a radio wave continues forever and ever, and that the copyright owners need appropriate protection. Of course, broadcasts do NOT continue forever, but will eventually dissipate into nothing. More importantly, if the Martians ARE watching reruns of "Lucy" and "My Mother The Car," copyright claims would have to be pursued in Martian courts.

There are, as far as we know, no Martians or Martian courts, but the example is a useful illustration. Copyrights and patents granted in the US provide protection in the US, and not necessarily in other countries. If you plan to market your new Killer Application or Better Mouse Trap in the EU, China, and South America, make sure you have enforceable rights in each region or nation. A boilerplate statement that "Vendor reserves all intellectual property rights anywhere in the world," may simply not do the job if you will be doing business in a nation that requires special registrations or which does not recognize US grants of rights.

Boilerplate can be a drafter's friend, if he/she has a collection generally tailored to his/her field of practice. But both parties are best served if they read the boilerplate with the same care as the main business terms. After all, an error in the boilerplate may not be simply "harmless error" that will not disrupt the deal.