Roadblocks to Quality IT Service Recovery Documentation


Successful IT service recovery depends on the quality of the documentation not destroyed by the disaster. So, what keeps organizations from maintaining quality documentation for IT service recovery?

  1. Lack of experience . Most people have not experienced a major business disaster that destroys their entire work environment. Further, few of us are interested in experiencing something like the Oklahoma City bombing to further our education in IT service recovery. The absence of experience forces organizations to depend on classroom training, designated experts, and simulated disasters to educate employees on what information they need to recover IT services after a disaster. Still, these forms of education do not convey the real impact of a disaster.

  2. Lack of interest . While organizationally essential, IT service recovery typically does not garner an employee's personal concern unless management demonstrates an interest. Management leads by example when it consigns recovery planning to a lower priority than day-to-day operations. Moreover, while maybe not intended, recovery planning inadvertently scrutinizes what it attempts to recover. It should come as no surprise that the effort frequently uncovers chronic organizational shortcomings in need of improvement. Unless management has a formalized quality management program in place, these inefficiencies tend to fall to the pressures of day-to-day activity. Employees are quick studies. It will not take long before they do not even bother to report these issues to management. Employees quickly learn that there is no glory in recovery planning.

  3. Dynamic environment . As little as 10 years ago, a purchase influencing IT services had the potential of being a huge occurrence. Today, the rate of IT service “ related purchases have increased to a daily flow. Configuration changes now occur on a daily basis. The software "bug" detected yesterday may be enough to develop a test patch you can download today. Browse a site on the Internet, and it will update the software on your computer to make sure your browser can handle the site's special features. After the data, IT recovery depends heavily on the hardware and software inventory. Today's business environment is so dynamic, this changes every day. There are software tools available that will generate viable configuration documentation.

  4. Increased information volume needed for recovery . The configuration parameters in today's desktop operating systems exceed tenfold the parameters found in yesterday's mainframe. The standardized configuration frequently used to ease administrative workload in the mainframe environment has given way to unique configurations on every computer. The real kicker is that some of these parameters, especially security-linked parameters, overtly alter your ability to use your recovery data. The absence of these parameters can stall your recovery process. In time, experimentation may grant access to the data, but the shear volume of parameter combinations makes this a very time-consuming route. Worst case, you may learn the right combination eludes discovery.

  5. Lack of testing . There are essentially two methods for verifying the validity of IT service recovery plans. You can have a disaster that forces you to use the plan, or you can simulate a disaster much the same way you would a fire drill. Not surprisingly, those organizations that test their plan have proven to be more successful in a real disaster. Unlike a fire drill, the time required for full testing of a disaster recovery plan often takes days. Organizations that implement disaster simulations for testing purposes frequently limit their tests to a fixed period. The test involves walking through the recovery process and documenting each problem encountered until you have to stop or the allotted time runs out. Early tests frequently stop before the time expires , as someone discovers the simulated disaster destroyed some information key to recovery. Comparing the documentation from one test to another provides a good gauge on the improvements made in the recovery plan.

  6. Lack of controls . In this context, "control" refers to the policies, procedures, practices, and organizational structures designed to provide reasonable assurance that business objectives will be achieved and that undesired events will be prevented or detected and corrected. Organizations that fall short in addressing internal controls normally find it very difficult to maintain useful IT service recovery documentation. The preliminary assignment to develop a business recovery plan may produce the finest documentation money can buy, but following formation, the quality of the plan will hinge on the organization's controls.



IP Storage Networking Straight to the Core
IP Storage Networking: Straight to the Core
ISBN: 0321159608
EAN: 2147483647
Year: 2003
Pages: 108

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net