From afterthought to preconception, many aspects of IT are now being designed into systems and networks at the earliest possible stage, i.e. when the first specification documents are drawn up. Code testing, performance, and security can all be part of the spec and developed and enhanced together with the application functionality. Sure, reliability and availability are usually part of the design and the project goals too, but the case is now strong for making disaster recovery part of the IT solution DNA as well.

Three technologies that have recently achieved great popularity can help IT teams build DR in from the start.

  • Cloud computing. One solution is to hand off disaster recovery to a managed service provider (a DRaaS or Disaster Recovery as a Service solution). The MSP must be brought in early enough to design the DR facilities required, according to objectives such as RTO and RPO, and should also be encouraged to contribute input about ways of making the cloud system or application make DR more effective. Alternatively, enterprises can set up standby or mirror systems from the start, also in the cloud and leveraging the pay-as-you-go feature of most cloud service providers to keep costs down.
  • This drives much of IT today, including cloud computing, but some companies prefer to continue doing virtualisation by themselves. With clear planning and IT automation, virtual machines can be created (“spun up”) as required, keeping them on but idle for hot standby, or spinning them up in minutes for warm standby. Like the cloud, VMs let you replicate and prepare for possible disasters from the moment you start a project or a deployment.
  • Mobile computing devices (notably smartphones). There are two sides to this coin. First, mobile devices used for work will need to be incorporated into a disaster recovery plan. Second, they offer a powerful vector of communication to execute a DR plan properly when required. In both cases, there is much to be gained by integrating their DR aspects as early as possible into developments and deployments, rather than bolting them on afterwards.