The ideal arrangement for ensuring business continuity involves having a hot secondary datacenter that is located...
hundreds of miles away. That way, operations can be shifted to the backup datacenter in the event of a regional disaster. The main problem with this approach, of course, is that it is expensive.
Since building a replica datacenter is usually only an option for the largest organizations, smaller organizations must come up with a more practical and cost-effective solution to their business continuity needs. One option for coping with this problem is to build a secondary datacenter on the fly.
Although this option probably sounds even less practical than maintaining a standby datacenter, I have seen this approach used in the real world and it worked out surprisingly well.
This particular organization had long held a contract with a local hardware vendor. The contract basically stated that the organization would purchase all of their hardware through the vendor in exchange for a discounted rate. The organization also purchased an annual maintenance contract from the vendor that required any hardware issues to be resolved within a specific amount of time.
When the maintenance contract came up for renewal, someone decided that it would be a good idea to renegotiate the contract based on the organization's business continuity needs. I won't go into all of the granular details, but there were two key provisions that proved to be more important than any other.
First, the contract required the vendor to stock duplicate hardware that was to be dedicated to emergency situations. For example, if the organization purchased 10 servers of a particular model, the vendor would order 11 and keep the extra server in the box, in a secure location as a standby spare that could be used if a server were damaged beyond repair.
The other provision was that in the event that the organization's primary datacenter were to become incapacitated for a specific length of time, the vendor would help the company deploy a makeshift datacenter within 24 hours at a facility that the organization was renting in the next town. Although the organization never experienced a catastrophic failure that warranted the deployment of a makeshift datacenter, they did stage two drills to make sure that the vendor could deliver what they had promised. Both times, the operation went off without a hitch.
The vendor was involved in every step of the process. They provided the gear and assisted with both the failover planning and the actual failover process.
The situation that I just described happened a long time ago. Technology has changed a lot during that time. Even so, the lessons from the past are just as relevant today as they were back then. Involving your vendors in your business continuity planning can help to ensure that critical resources are available when they are needed most. Of course, the real question is the best way to involve vendors.
One possible option is to negotiate the use of the vendor's own datacenter as a disaster recovery site. This option won't work in every case, but it is becoming increasingly common for enterprise hardware vendors to operate public or semi-private cloud environments and lease computing resources to customers on a short-term basis. If your vendor offers these types of services, then you may be able to negotiate an arrangement that would allow virtual machines to fail over to the vendor's cloud in an emergency situation.
Of course not every vendor has their own cloud. If your vendor does not then you might be better off taking advantages of your vendor's knowledge than their on premise hardware resources.
For example, if your vendor has a certified partnership with Microsoft then you may be to work a deal that would allow you to fail critical business workloads over to Windows Azure in emergency situations. There are a couple of advantages to having the vendor perform the configuration. First, a Microsoft partner typically has access to resources that a typical Microsoft customer does not have access to. This means that your vendor may be able to call on experts within Microsoft to ensure that your failover environment is configured correctly.
The other advantage is accountability. If you have a signed contract from a vendor that guarantees a specific SLA for critical business processes then you may be entitled to compensation in the event that the SLA is not met (depending on the terms of the contract).
Even though this article used Microsoft partners as an example, the same principle can easily be applied to just about any technology provider. For example, you may be able to capitalize on a vendor's Cisco or VMware expertise in an effort to ensure business continuity.