Data protection service level agreement: implementing SLA support based on infrastructure design. (Storage Networking).

High data service levels provide opportunities to the most common organizations: small businesses, workgroups, and small departments. This article is the third in a series of five that address the creation and maintenance of simple, effective service level agreements (SLAs), to reduce risk, improve operations, and encourage growth of the common organizations.

Implementing support for the data protection SLA entails a spiraled cycle of process definition, testing, and feedback. Process definition begins with writing a draft of the backup and recovery processes. These processes must accommodate both the priorities defined in the business data inventory and the business process information gathered from stakeholders. The data originally collected in formulating the SLA may not provide sufficient information to create complementary and supportive data protection processes, prompting further interviews, research, and analysis. For example, SLA development may have revealed that certain accounting spreadsheets must be filled out by close of business every day, as well as the data flow for filling them out. It may not have detailed the personnel involved and contingency plans if those persons are unavailable. This additional data provides critical input to formulating the backup and recovery processes. Recovery scenarios likely involve the cooperation of key users, and/o r just as likely, their alternate, should the primary user be unavailable.

Data Stakeholders

The backup and recovery process draft consists of step-by-step procedures for the backup and recovery of each set of data in the business data inventory. It also includes a high-level description of how each step in each procedure is prioritized among all the steps and procedures that must be executed. This high-level description also identifies areas where simultaneous execution of any of the steps or procedures can either create synergies or conflicts. Guiding principles in forming this draft is to keep it simple: Users should be able to understand any process without a translator or much training. The draft must also include a data dictionary that specifies technology- or business-specific terms and acronyms, as well as any potentially ambiguous words or concepts.

The IT staff should review the backup and recovery process draft with data stakeholders, focusing on priorities and accuracy of the business processes and priorities represented. This stage of implementation offers the IT staff a chance to review and revise the stakeholder analysis created when formulating the SLA. It also gives the IT staff a chance to more accurately identify all stakeholders affected by each process, as well as their interest in the data itself. The most careful planning does not often reveal implementation impact on all stakeholders. Often, this information only comes from actually creating the processes, and trying them.

Therefore, it is important to implement processes in a stepwise, incremental fashion, with tight, simple, feedback loops. The first challenge is to decide how to break the implementation into testable portions. These portions should be able to stand alone in terms of definition without dependencies. The portions should also be testable at the business-process level, answering the question, "Were we able to resume the business process within the time and function specified in the SLA?" The portions should also enable logical engagement of required help from vendors or contractors. For instance, if onsite support from one vendor is required for a number of portions, it might make sense to combine one or more of those portions to reduce vendor-engagement overhead.

For each portion of the implementation, testing should involve as many stakeholders as possible. This involvement accomplishes many goals, including the preliminary feedback on the validity of the processes, first-hand information on ease of execution, initial training on the processes, and end-user community buy-in to both the processes and the SLA. The key to success in accomplishing these goals is to capture as much information as possible on the stakeholder experience during the testing period. This feedback can be primarily a voluntary response to a solicitation, or, in more critical situations, should be collected through interviews or automated observations, such as number of mouse click tallies, failure count, or time to complete a step. Analysis of the information gathered from the tests indicates any required revisions to processes, communications, the risk model, backup/recovery plans, and the SLA.

Change Control Processes

Creating a simple change control process can yield the tight, simple feedback loops needed to keep processes on track and continue to fulfill the SLA. Most change control includes both synchronous and asynchronous processes. When first implementing the infrastructure to support a SLA, synchronous processes may take the form of short, frequent, small meetings to review progress and test results. As the implementation matures, meetings should be held on a less-frequent basis (e.g. quarterly) to ensure user satisfaction and backup/recovery process/execution readiness.

Asynchronous change control processes present a more complex landscape that can be simplified on an ongoing basis. One technique for asynchronous change control involves the use of triggers. This technique offers value to common organizations due to its simplicity.

A trigger is a detectable state or event that indicates change has occurred or will occur. Change requests from stakeholders are triggers. Performance outside measurable objectives can provide other triggers. The measurement of performance with respect to fuffilling SLA objectives will be the topic of the next article in this series. Other examples of triggers are business events, such as corporate strategy changes, organizational restructuring, fluctuation in workforce size, and modification of business processes; or technology evolution, such as business application changes, new infrastructure offerings (connections/bandwidth, systems/operating systems, integration services, support software), and anomalies (bugs, security alerts, and viruses), iT staff traditionally manage change by providing mechanisms that react to the triggers, keeping in mind that triggers may indicate proactive or reactive processes. Figure 1 depicts this management approach.

Any change control process prescribes three basic mechanisms to manage change. First the process must perform change action appropriate to the trigger detected. Often those actions will involve changes in procedures and process. Second, the if staff, along with any appropriate stakeholders, should briefly review the situation that set the trigger, and the results of the ensuing change action. Third, the if staff should add all information on the changes (including trigger, action and results) in the change database or other change tracking system. For both synchronous and asynchronous changes, the IT staff is responsible for notifying all affected stakeholders of changes, prior to implementation of the change, if possible.

A practical example of implementing a SLA is in process at a Madison Avenue investment firm, Cramer, Rosenthal, McGlynn, LLC. A high-level definition of service levels resulted from a series of interviews. Top-level goals included recovery of all critical applications within one day, and all applications within a week. These goals prescribed remote backups, as depicted in the designed infrastructure, Figure 2. The company is in the second stage of implementing this infrastructure, and plans to exploit disk caching for backups, to address backup window issues posed by the T1 connection. Recently, the IT staff performed risk analysis to provide the basis for a completed SLA. In conjunction with the formulation of the SLA, the IT staff will document recovery processes and begin stakeholder training/practice of those processes.

The next article discusses the measurement of service levels and methods for managing to those measurements. The last article in this series addresses a vision for the future of data protection services for common organizations.

Lynne VanArsdale is senior strategic marketing manager for Quantum (Irvine, CA) and a member of SNIA board of directors (Mountain View, CA).

www.quantum.com

www.snia.com