The Perils of Chargeback

January 6, 2007

I shall soon post a discussion of the first question in Schneier’s framework, and how it relates to disaster recovery, but as I thought about it, I realized that I both wanted to discuss chargeback, and that the points that I wanted to raise would inappropriately dominate the discussion. So I’m separating chargeback into this post.

When dealing with the problem of categorizing data from a broad set of organizational entities, the chargeback approach is quite tempting. Forcing your organizational customers to make their own value judgements about the availability and reliability of their data both eases your role and can lead to better assignments. After all, your customers are the ones who understand their data requirements best (hopefully). However, your role as disaster recovery expert should lead you to be cautious in relying solely on chargeback. You need to be the individual (or set of individuals) who is responsible for taking a broad, holistic view of disaster recovery planning.

In particular, there are two ways that chargeback can lead to poor disaster planning:

  1. Your organizational customers are not experts. They may make poor value judgements in an effort to spare their budgets, and
  2. Many organizations do not operate as profit centers, yet are crucial to the operation of the overall company.

When establishing a chargeback process, you must make sure that you are available for DR consultation, and proactive about communicating risks. Use the DR framework to establish guidelines, not just for first-order categorization, but for the process of examining second-order impacts. As an example, don’t just establish the basic three tiers (mission-critical, business-critical, non-critical) of data and ask each organization to wedge their data into them. Ask the businesses to run through the scenarios of what would happen in each failure case. What other systems would be affected? Who else would have visibility into the failure? How would schedules be affected? Would customers be affected?

You should be spending a great deal of time worrying about these questions: dreaming up failure cases, guessing at their likelihood, and running through scenarios. You should take the opportunity to share the pain. (Side note: I don’t know about you, but I find it actually depressing to spend too much time thinking about failures, and I also find that talking about them with other people cheers me up a little. Although it probably depresses them. I can be a real downer at parties.)

As far as budgets go, a chargeback system should be sensitive to the size of an organization’s budget relative to the importance of its data. An R&D group, for example, may not be given much budget, but the intellectual property contained within its systems may represent huge value for the company. If the budget masters of the company dole out funds without earmarking anything specific for disaster recovery, the temptation of the managers is to direct their funds towards resources that may eventually pay off: e.g. research. Nobody I know, when they get their budget requests, says, “Great! Now I can finally afford to have my data remotely mirrored!” I’m in favor of discounting chargebacks based on whatever criteria you find appropriate, but other approaches can be used.

A laissez faire chargeback policy can be a great cover-your-ass strategy. When disaster strikes, as long as the system that you’ve designed behaves as you’ve predicted and advertised, you can defer all responsibility for any unpleasant side effects. If an organization loses critical data, you can say, “They should have paid for better storage.” If the company is impacted by the losses of a single division, you can say, “They should have had a bigger budget.” But here’s where my squishy liberal side comes into play: the people who play the role of disaster recovery managers should consider themselves responsible for the welfare of the entire company. They should have the flexibility to set policy with the good of the business in mind, and they should be responsible for evangelizing comprehensive and rational disaster recovery planning.

Your job shouldn’t begin and end with the design of storage systems. You should be a shepherd, guiding your company through stormy nights and the occasional hurricane.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: