Last year I had the opportunity to meet a senior member of a former client’s executive management team while we both spoke at a conference in Miami. I began by asking him if they still did a Peace Business Continuity BIA before any new system was put in place. He smiled at me and said, “So you’re the guy who worked with so and so back in 2000.”
One of my priorities then and now was to insert BC/DR considerations into the System Development Life Cycle (SDLC) so they would be addressed up front. There are some very important reasons for doing this.
Every major change should be preceded by a focused BIA. A properly conducted BIA for the change will identify what new pressures will be brought to bear on the current state recovery strategy. New applications, business functions, and infrastructure changes can have a discrete and, perhaps, debilitating impact on disaster recovery strategies and business continuity planning. The BIA should be used to measure outage impacts for the new change and be used to measure the overall impact on recovery requirements. If the SDLC includes a BIA hook, it’ll happen.
Each BIA Impact Category should have a list of recovery requirements. For example, at the client mentioned above, I used the categories we developed in our Y2K work to separate the most critical (AAA) from the more deferrable (D). I then used the categories to delineate what recovery requirements each new application needed to include in their planning. For the AAA through B ratings, the developers were required to include local failover (multi-processor environment), remote failover at the recovery instance, written recovery plans for the application and business units supported, and annual failover recovery testing. Putting those requirements early in the SDLC made for far better upfront planning and trying to retrofit them later would have been impossible. It eliminates the ‘but nobody told us” excuse.
BC/DR considerations must be included in the budget. The final price has to include provisions for recovery from the very beginning because there will be no money available later. For example, a new AAA application will be required to run in a multi-processor environment for local failover, not a single-threaded server, and another one is needed in the recovery environment. Now we’re talking about two specialized servers, not one and some possible impact on the network response time. The project budget should include this additional capability. Pricing things right in the beginning will mean an accurate assessment of the true costs.
A Gap Analysis should be performed to determine the overall impact of the change. The current state recovery capabilities should be examined to determine if the change will open any gaps in the company’s ability to recover critical business functions in the timeframe required. The change can impact the data center, data and voice networks, and business area recovery, or all of the above. Any gaps discovered can affect budgets and project delivery timeframes and priorities.
Here is what you’re trying to accomplish: At some opportune point between the time some executive says, “That’s a great idea” and the time they reach for their wallet, you want BC/DR considerations to be addressed so the real price is known and the implementation plan is written accurately. If there are BC/DR hooks in the SDLC, all the recovery issues are addressed in a timely fashion and the fixes won’t need to be bolted on later, if at all. As always, leave some comments or contact me directly if you’d like.
© Copyright and All Rights Reserved Howard M. Peace