We are currently looking at adding disaster recovery (DR) into the systems
development life cycle (SDLC) of all our new projects. Until now, DR has always been an
afterthought. What are some best practices for getting a DR solution up and running with our new IT
projects?
Requires Free Membership to View
If you plan to use a traditional systems
development lifecycle (SDLC) approach, disaster recovery can be addressed at several points in
the SDLC process. Perhaps the most important part of this activity is having senior management
support for inclusion of the disaster
recovery process. Without this, you will probably not be able to secure additional funding that
may be needed for DR. Having said that, let's examine how DR can be integrated into the SDLC.
- Feasibility study: This is a logical place to introduce a disaster recovery process, as
it will encourage you to consider the criticality of the system to be implemented, the financial
and operational impacts of the system failing, or being disrupted and the threats to the system,
both internally and externally. A feasibility study may also point out possible vulnerabilities to
system operations that can be factored into the system design.
- Requirements definition: Be sure to define all of your requirements and incorporate a
disaster recovery component to learn what prospective vendors (if this is an external system) will
offer to ensure the uninterrupted operation of their product and what remedies are available to
recover the system if it fails.
- Design/selection: When designing and selecting your system, include disaster recovery
requirements so that they will not be overlooked by vendor candidates. Also, include DR
requirements in requests for proposals
(RFPs) that not only address the system being considered but also delineate what business
continuity (BC) and DR plans the vendor has to keep it in business so it will continue to be
available for technical support, maintenance, enhancements, etc.
- Development/configuration: These phases offer useful opportunities to validate and test
the disaster recovery capabilities of the proposed system(s) before it is placed into production.
- Implementation: During the SDLC process, be sure to document the DR capabilities of the
new system. Perform disaster
recovery tests of the system and record what changes were made to the system based on the
tests. Also, create a step-by-step DR
plan that specifies actions to recover the system after a disruption. The plan should specify
where system data backups are stored (frequency of backup, type of storage, etc.), where database
backups are stored, and even where backup hardware components are stored.
- Post-implementation: As part of scheduled maintenance, include a DR test at least once annually; for any approved system changes, update the DR plan documentation as needed to incorporate the changes (conduct a simple tabletop test to be sure); and make sure all users of the system area aware of the disaster recovery process and what they should do if the system fails.
Beyond the steps above, ensure that the organization has a formal disaster recovery policy in place that makes it mandatory that all production systems have 1) documented DR plans; 2) at least one annual test with post-mortem; and 3) at least two technicians who are fully qualified to operate the system and fix it in an emergency. If you follow these best practices for implementing disaster recovery in your SDLC process, your system and projects should run smoothly.
This was first published in July 2010