For business continuity and disaster recovery plans to succeed, data protection must be considered an integral part of any organization’s IT and corporate culture.
The way a company does its information technology — systems, support and strategy — is part of its culture. One could even argue that anything ingrained in an organization’s culture gets done and the rest doesn’t.
Backup tasks often don’t affect corporate culture. They probably should, but they typically don’t. Instead, backup is often seen simply as a bunch of after-production tasks to make one or more (often a lot more) copies of what’s in production. That explains why so many business continuity and disaster recovery (BC/DR) plans suffer atrophy — they’re often developed within the vacuum that is IT, and therefore don’t affect the ongoing organic culture of the organization.
BC/DR preparedness has to affect corporate culture. Why? Because if you developed a BC/DR plan that hasn’t affected corporate culture, that plan became out of date the day after you published it. You need to recognize that production environments continually change: new servers are added, machines get moved and the critical nature of services changes. If you haven’t made preparedness part of production, then when the changes happen in production, they won’t be organically reflected in your preparedness plan. And when it comes time to actually fail them over, you won’t know about them because your documentation effort stopped the day your plan was published.
BC/DR planning has to affect corporate culture so that as production evolves, your BC/DR plan evolves as well. For example, whenever IT decides to stand up a server or a new service, the first questions its operations person should ask are: “What do we need to do to update our BC/DR plan accordingly? Should we start replicating that virtual machine? How often should that server’s data be protected? How long should the data on the server be retained?”
Answering those questions takes more than the backup admin’s opinion, which is just one of the many reasons why BC/DR planning requires a wider effort. In the broader sense, the initial BC/DR initiative, the first BC/DR plan, the ongoing “preparedness as part of production” culture shift, and the recurring BC/DR plan testing and maintenance all take a multi-member, cross-functional team:
- Executive sponsorship is needed to ensure that the plan does affect culture. The backup administrator isn’t going to change the culture of the IT team, much less the culture of the whole business.
- In many cases, you, as the backup manager, don’t have enough information to understand (as production changes) what related changes the BC/DR plan needs to receive. Often, that’s where tech tools can help; they can assess what’s on the wire through discovery and potentially tell you what the interdependencies are, which is hard to discover otherwise. You have to know how your production environment is evolving, so your BC/DR team can sustain and evolve the BC/DR plan accordingly.
Preparedness has to be part of production. It’s a cultural change that’s dependent on a technology-level understanding of what is in, and what is evolving with, the IT infrastructure.
This emphasis on needing a broader team than just the backup staff won’t diminish the value of their role. After all, no amount of process or procedure will help if the data doesn’t survive the calamity. The good news for backup administrators considering their participation within a BC/DR framework is that the conversations BC/DR planning drives may actually help a backup administrator get to a managers’ desk or a corner office.
- A backup admin manages; a BC/DR architect leads.
- A manager is tactical; a leader is strategic.
When you think about ways to affect culture, to convert technical challenges into business challenges and solutions, that’s when you go from being a manager of backup tactics to a leader of BC/DR strategy. Not only will your company benefit from the better preparedness as part of production, but the view from your desk might improve as well.
[Originally posted on TechTarget as a recurring columnist]