Data protection service level agreement: implementing SLA support based on infrastructure design - Storage Networking

Computer Technology Review, July, 2002 by Lynn VanArsdale

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.