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?
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.
Dig Deeper on Disaster Recovery Planning-Management
Related Q&A from Paul Kirvan
Explore the benefits of using an open source backup software platform, with a focus on Amanda, a popular product in the field.continue reading
Learn what can disrupt service for WANs and LANs, and identify key criteria for network recovery following a disaster.continue reading
Your organization's risk assessment plan should account for the increase in severe weather events and the damage they can cause.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.