Closing the Loop to Compliance — Part I
Users react well to questions about recovery—if they are asked earlier. For those finding out at the 11th hour after already securing their budgets, the story is not so compelling. They didn’t obtain money for equation’s other part. They say, “We can’t cut back on production,” therefore we will cut back “on the recovery side.”
But the reality is if they had just built in the architecture to begin with, there would be availability in the first place; it wouldn’t be an issue.
There are so many people that are virtualized—not in a Cloud computing sense—but an entire entity. They embark on projects and they separate and come back together. There is no margin for error. While this is maybe a tactical example, when talking to customers, most organizations are so sensitive to revenue loss, that a five per cent decline in revenue is catastrophic. It becomes the first domino that starts to fall. RIM now Blackberry’s problems are an example or Michael Dell’s having to take Dell Computer private to keep Wall Street out of this business—that’s just taking your eye off the ball and the resulting domino effect started to cascade.
The Challenge of Post Disaster Regulatory Compliance
From a compliance perspective, the issue is that in a post-disaster situation, companies no longer get a pass. They absolutely must maintain their compliance posture post disaster. Most acquire the bare minimum recovery capabilities to allow them to update applications but with little or no consideration for regulatory demands.
From a co-location perspective, companies in the past would resort to co-location for ‘grow your own’ disaster recovery.
They will deploy either aging assets, machines that have retired or they rig machines formerly used for QA or other work. They’d say, “If we have a disaster in a production environment, we will just repurpose these assets on a temporary basis” and the cheapest way to do that is “to use co-location.”
Very few companies can stop development to avoid disasters They can’t stop development so easily. Or they are not prepared to stop QA as there is still have a business to operate. The short-sighted perspective is ceasing to do work note viewed as core to our business—like QA and development when the reality is that so many businesses more or less circle around online applications. There is no longer the luxury to say, “We will suspend this sort of function.
Co-location may be inexpensive but with the assets needed to put into it and all of the effort required to maintain it is actually expensive. Co-location is really not the right approach to solving a business application availability issue. It simply is not.
Part II: Closing the loop...