Mar 25, 2015 | Blogs, Resources

How Companies SHOULD plan for Disasters – Part I

by Craig McLellan, Founder and CEO

The approach companies have taken to planning for disasters has quickly become obsolete as the interconnectedness between business systems has increased.

While it may be a cliché, it is true that the best disaster to deal with is the one that never happened. You can experience this in one of two ways; you can cross your fingers and hope the law of averages in on your side or you can adjust your optics and look at a disaster as a design flaw.

Let’s use the analog of car design. With the establishment of freeways car manufacturers started building faster cars capable of traveling long distances. These cars needed to be large enough to protect the occupants during a collision. As the cost of car ownership increased manufacturers started building lighter, smaller cars. These smaller cars lacked protection associated with size but instead of building more hospitals along the freeways the manufacturers started to innovate within their designs. A crumple zone within a car’s body couldn’t be planned after market – it needs to be part of the inherent design to the point where the typical user doesn’t even know it’s there. Today, we take these features, along with a multitude of other functions for granted but when it comes to our computing infrastructure we spend too much time trying to get an application out the door with no regard to how to avoid injury at high speed.

Companies on the forefront of Disaster Recovery are focusing on addressing the disaster before it happens. Whether the disaster is Catastrophic or Clinical in nature there are a variety of steps a company can take to reduce their risks. The key step to this new approach is to focus on the architectural availability during the application development and deployment phases. The survivability of an application or its entire ecosystem is MUCH easier to address during its development; API and Web Service layers can be written to tolerate latency and interruption and data replication techniques can be built into the application itself. Even simple recovery techniques such as the automated removal of corrupt data can have a big impact on the availability of a company’s critical applications

Connect on Social