Business Continuity and ILM: a layered availability solution

Computer Technology Review, August, 2004 by Adam Mendoza

Although Business Continuity (BC) and Information Lifecycle Management (ILM) are not generally viewed as related disciplines, it is without a doubt that they both have one basic premise in common: ensuring data availability. Add Disaster Recovery (DR)--which, although often discussed in the same context as BC, is different in that it is more often employed in extremes as its name suggests--and you have the tools to provide:

* Users with the highest levels of application data accessibility

* Corporations with economic and government compliant solutions

* Enhanced shareholder value (at a minimum, a corporation must prevent degradation of corporate value due to a perception of risk.)

Balancing the requirements of these disparate constituencies is the primary challenge when considering the right availability solution.

Balancing Availability Requirements

User Application Data Access: IT departments frequently view end-user demands as unreasonable and impossible to satisfy, primarily because complex computing environments are both costly and wrought with unpredictability. This unpredictability is the primary consideration in all BC and DR solutions; it is why they exist. So what makes user demands unreasonable? After all, they simply require:

* No disruption to their day-to-day business operations and tasks

* High performance with no apparent latency between task requests and completion

* No limits on growth regardless of the business value of the information

* Immediate access to that information despite its creation date

Not unreasonable for a handful of users perhaps; but when these demands are multiplied by 100 or 1,000 or 10,000 individuals, the environment becomes difficult to manage and potential issues and problems become impossible to predict. However, breaking down each demand into legitimate requirements can help determine the quality of service (QoS) levels that are truly achievable.

For instance, planned disruption--otherwise known as maintenance--can be scheduled so that only the minimum number of users are affected and, for those affected, off-line techniques can be employed to further reduce this inconvenience (there are many application and data synchronization dependencies implicated by this scenario). To minimize this disruption further, alternative on- and off-site computing resources can be utilized to shift the workload while maintenance is conducted or while unexpected issues are resolved. Therefore this requirement can be summarized and refined to state:

This X-application and X-data is required to be available during this X-period. In the event of an outage, this X-mechanism can be utilized as long as the affected data is synchronized within X-period of time. The maximum period of disruption cannot exceed X-period.

The infrastructure solution that results to support this particular QoS will incorporate load balancing, resource availability to process new tasks and associated data, and mechanisms that can be employed to serve requests for data previously processed and stored. Integrating infrastructure solutions with data policy definitions (e.g., the importance of the application and its data, the time limits associated with data access, and the relative prioritization of the application through downtime tolerance) form the basic tenants required for BC and DR.

Note that ILM requires yet another level of policy definition: Retention. How long data must be kept and what infrastructure is required to make it accessible and usable are important ILM considerations. This last policy definition must take into account the combination of user and corporation requirements, which are in turn driven by the government (e.g., Sarbanes-Oxley regulations).

Corporate Considerations: Unlike end users that generally believe that all data is created equal (i.e., every e-mail sent is important, every document vital), corporations have certain applications and data that are more critical than others based on relative business value. In addition to classifying the data, the corporation must also design, implement and maintain the supporting computing infrastructure.

Many corporations have already defined the applications that are considered critical, and they typically rank customer-related data as one of the most important sets of data. Making these distinctions are the first steps in the development of effective BC and DR plans.

This type of classification process was brought to new levels of importance just before the turn of the century with the implications created by the year 2000 or Y2K. Many corporations did not have any type of methodology, disciplines or mechanisms to determine what applications and data were the most critical, and more importantly, what risk they were incurring if they did not have the application and its associated data ported to compliant platforms. Corporations learned from the Y2K "fire drill," developing basic risk analysis techniques and converting this knowledge into very useful BC and DR plans.