Art! Where's my data?

Data backups are not as simple as it used to be (If it was indeed ever thus!). Modern ways of working means that a great deal critical data is likely to reside offsite rather than on your treasured backup tapes! Danny Davis points out that we should respond to this trend by including offsite data in our backup and disaster recovery (DR) regimes.

 

Art! Where's my data?

 

Let's be honest, when was the last time you looked into your data protection issues? Think about it. Tape retention cycles and offsite data handling are basically an automatic assumption in most IT production settings these days. You should be able to have some confidence that your backups are being performed, verified and data recovery tested on an appropriate basis.

And although I am personally horrified by the number of times I see this is not actually the case, that isn't what this article is about. But, as an aside, good governance should be alerting you to exception reporting (failures) – and failures do happen. If you haven't heard anything recently, chances are that no news is not necessarily good news.

It's about protection, silly

But let's get back to the basics for a moment. Why do we do those pesky backups anyway? Protection. Protection from loss of data due to failure, disaster, corruption or deliberate damage. Data protection should enable us to achieve an immediate recovery from crisis and to reconstitute data that may have been lost or damaged at a particular time in the past. A day, a month, a year… Our tape retention cycles and offsite storage are the tried and true ways of achieving this outcome. But here, as everywhere, the world continues to change and the rules of the game are changing with it. Just five years ago we were winning the battle of bringing our data into the computer room. Where it was safe. Where we could put our arms around it and give it the love and attention it deserved.

And, suddenly, without warning, things have exploded again beyond our immediate control. Our email is externally hosted. Transactional data is transitioned through the DMZ (de-militarized zone – the bit at the edge of the firewall) hosted alongside our corporate website. We are looking at using a Software-as-a-Service (SAAS) solution for our training management.

Our strategy development is in a hosted wiki. Our development outsourcer is maintaining our legacy apps. Our infrastructure outsourcing is providing data mining as a shared service on their central supercomputer facility. Market intelligence is gathered through our collaborative arrangement with our strategic alliance partners. It's all going swimmingly: amazing leverage; best-of-breed; time to market; collaboration and strategic alliance... and control slowly starts to slip through our fingers like a handful of sand on the beach. Then one day we are struck by a sudden realization – do I actually really know where my data is now? Sure as clams is clams, it's not on your backup tapes.

What would recovery even mean if there was a failure in my outsourced partner? What use would a tape backup of their infrastructure be to me then? Why hasn't this appeared as an issue on my governance reporting? Who's at the wheel? What is going on?

Back to fundamentals

Take a deep breath. Settle down. As always, traditional business management practices are there to save the day – if we apply them well. If we use a little innovation in the way we apply them. If we remember at all times the fundamentals of what we are here to achieve. For starters, it's vital that data protection and data quality management are a fundamental part of any service we purchase. If we can only buy functionality but not data management, we don't have a deal. It's part of the service. It's documented in the service level agreement (SLA), measured and reported. If the service provider is not up to providing that aspect of the service, then it is a service we simply cannot afford to buy – no matter how attractive the price might be.

Our corporate IT policies and standards apply to the services we consume, not just the services we deliver using internal resources. So, what data is being kept for you by your service provider? Are email archives held offsite? What about your BlackBerries? How about if you are using some other SaaS or hosted solution? What data is your IT operations outsourcer or application maintenance crew holding on your behalf?

Retrieving meaningful data

Do you have clear rights to retrieve this data? Do you have methods of retrieving your records? The last thing you want to be doing is negotiating technical arrangements for data transfer after a contract is signed. Worse still, if you are trying to deal with it at disaster time, when your service provider is in crisis mode or engaged in business shutdown mode. Worse still if they are overseas.

A service provider 'transitional' data recovery programme should be agreed, documented within contract and tested regularly. You must be serious about including this offsite data as a part of your backup and disaster recovery (DR) regimes. You need to have visibility and a reminder for a programme of regular review and test. If this lives within your backup and DR plans and engages with your corporate risk management strategies, you may have a fighting chance of maintaining control over these resources over the longer term. Keep in mind that it is one thing to retrieve your data but another thing altogether to make it meaningful. Getting data dumped from one corporate application into another one can be a hellish task and should not be underestimated.

When considering transitional data retention, don't forget data hidden within the configuration of your offsited applications. The more complex the product, the more likely it is that there are all sorts of customizations and configurations that have been implemented specifically to address the needs of your company.

Documenting and managing these customizations is critical to making a process of recovery on another platform survivable. It is too easy to fall (or be pushed) into the trap of believing that application A on one service provider will be the same as application A with another service provider. That may be how it is sold, but it is unlikely to hold true in the heat of the moment of transition.

In order to be able to plan for a transition of data at disaster time, you need to have some concept of where that service will be reconstituted in the event of a disaster. We are good at doing this for our own systems (safe inside our computer room), but rarely look into it when the services are housed offsite.

If the disaster scenario involves the 'liquidation' of a service provider, do we have current data? Do we have systems capable of reading and making use of that data? I think you get the point.

The bottom line is this. Each service you subcontract (or deliver through a partner) should have a clear and documented SLA. SLAs must include a standardized definition of how data is to be handled, backed up, tested and, when necessary, transitioned.

With each swing of the pendulum we have a tendency to lose sight of the basics. We go to a new paradigm and believe the hype that all our problems will be solved. New paradigms are good – but the need for good management practices does not go away. Don't be one of those who will learn their lesson the hard way, again.

You don't need to resist the momentum out of the data center and into the cloud, just make sure that it is included within a strong framework of governance and management practices appropriate for your business criticality. And then you can confidently assume that no news is good news and keep your focus for the more forward thinking aspects of your role.

About the Author

Danny Davis
Executive Director,
CIO Institute of Australia and Principal Consultant at Vandis Advisory.

The CIO Institute of Australia is the professional organization for senior IT executives. It aims to improve the standing of the profession through focused executive development for its members and outreach to the business community at large.