You can't always predict what natural or man-made disasters might befall your company, but if you think about it you can probably estimate the business impact of losing critical IT systems or applications. Imagine going into your data center and unplugging the power cords from your key servers (or information systems). Pull the plug on your order entry system, your customer relationship management system and even your data warehouse. The impact to your business would be immediately apparent as customers and suppliers would be unable to place orders or complete transactions.

If those systems remained unplugged for hours or days, the impact on your company's revenue and profits would likely be enormous. So it's important for IT managers and business leaders to understand which of their systems are mission-critical and why. However, mission-critical systems don't usually come with a big "MC" stamped on them.

While core transactional systems have always been considered mission-critical, over the past few years systems or applications that used to be considered supporting players have come front and center to core business operations. Such systems must be part of a good disaster recovery strategy.

The evolution of mission-critical data warehousing
With their focus on reporting and strategic analysis, data warehouses were originally considered by most companies to be non-mission-critical systems. If the data warehouse was down for a few hours or days, users could still perform core business processes such as taking orders or making sales.

However, over the past few years, organizations have increasingly come to realize that data warehouses are being used for more than static reports or strategic analyses—data warehouses are serving mission-critical roles in day-to-day operations. For example, a data warehouse might be used within a Web-based shopping application to help automatically analyze a customer's purchase history and provide optimized purchase suggestions or combination discounts. Or a data warehouse might be used within an online banking application to help craft a report that collects and summarizes a customer's transactions, from credit cards to online bill payments, giving customers a complete view of their finances.

Any organization using a data warehouse should re-evaluate its disaster recovery plan regularly (perhaps every year) to ensure it has a strategy in place to counterbalance the impact of potential disasters on key business systems. In many cases, this requires a change in the business and IT mind-set for data warehouse systems—instead of simply assuming they are not mission-critical, companies must proactively evaluate their day-to-day business impact and identify and implement an appropriate strategy.

Choosing the right option
A wide range of disaster recovery strategies is available—from dual-system solutions that enable organizations to get systems and applications back up and running in minutes to plans that exist on paper only. Each solution requires varying levels of investment and delivers different value. However, it's important to recognize that one approach does not necessarily fit all situations and companies.

In general, a correlation exists between the speed of recovery and the cost required to implement and maintain the solution. The faster an organization needs to get a system online, the more expensive it is to do so. Alternatively, the longer an organization can wait before a system needs to be up, the less expensive the solution tends to be.

Typical disaster recovery options fall into four categories:

	Planning only. A disaster recovery plan is a document that specifies what systems are mission-critical and how quickly they need to be brought back online after a disaster, and it includes a plan for different disaster and recovery scenarios. Like other options, paper-based disaster recovery plans should be tested occasionally to ensure their effectiveness. Planning-only recovery strategies are appropriate for situations involving smaller companies, less-mission-critical systems and scenarios with a lower probability of natural disaster. Systems that are considered "important" or ones that support the business may be appropriate for this level of disaster recovery planning.
	Third-party recovery solution. For situations in which a system or data warehouse has a significant business impact, organizations should consider a more advanced form of disaster recovery, such as third-party recovery solutions. These solutions enable organizations to locate redundant (or backup) systems and applications in another location, perhaps geographically separated, so that if a disaster occurs, the organization can have the backup systems up and running in days. This does not remove the requirement for a written plan, but it does represent a solution to meet that plan.
	Company-managed recovery solution. Organizations can also create an in-house recovery solution that provides redundant systems internally, perhaps at different corporate locations. This provides for increased security and manageability compared with third-party solutions and can have a lower cost. However, it may also require more maintenance, more staff and more planning.
	Dual systems. If the business impact of a data warehouse is truly critical for the business and it needs to be up and running minutes or hours after a disaster, then organizations should consider dual-system solutions. Dual-system disaster recovery solutions are essentially "hot" standbys loaded with current data, so that in the event of a problem with the main systems, the secondary systems can go online immediately.

Safeguarding your data warehouse
Reducing risk and being prepared for potential IT and business problems is just a prudent business strategy. The place to start, of course, is by ensuring that you have a plan in place for core business applications and systems. But it's also important to recognize that solutions like your data warehouse that were not originally considered mission-critical may now be mission-critical. Employees or partners may rely on them as part of key business processes. As a result, an organization should also make sure it has good disaster recovery plans in place for such systems. T

Selecting the right option for your data warehouse A business impact assessment (BIA) is the first step in determining the right disaster recovery option for your organization's data warehouse. The assessment can be very in-depth or it can be high-level. It's simply a way to express the business impact of an organization's IT solutions and systems. A BIA would define: > How much the company depends on each system > The processes that each supports > What happens when a system is unavailable > How soon each system needs to be up and operational after a disaster For example, if an organization has a Web-based sales application, every minute of downtime could mean lost sales, since the system will not be generating revenue. If the system is down for 30 minutes, the company might not lose that much money because customers may be willing to return after a short time. But if the system is down for more than 30 minutes, a 20% decrease in sales might result. If the system is down for longer than seven hours, the impact might be a 50% loss in sales. Estimating how much the loss of each system will affect revenue or profit is the place to start. That helps determine how much money to invest in a disaster recovery solution. It will also help guide the decision as to what kind of solution an organization needs. The assessment of each system must be as accurate as possible. If an organization invests too much in a system that does not provide much revenue generation, it is wasting capital since it has invested more than the potential return. However, if it invests too little, the company may experience a disaster and lose money because it will be unable to get its systems back up and running effectively. Organizations need to find a balancing point for data warehouse disaster recovery solutions, while trying not to over- or under-invest. Keep in mind that a BIA is focused on the business. That means that an organization needs to look at its business processes, what those processes support and what revenues are tied to them. In effect, creating a BIA is a method of investigating an organization's business processes, not a critique of its IT systems. —D.A.K.

David A. Kelly is a Boston-based freelance writer who specializes in business, technology and travel writing.

Teradata Magazine-June 2008