The emphasis in recent times in BC/DR planning has been on getting rid of the “silo” effect – the blinkered thinking that only takes into account one department at a time. By recognising that isolated business risk does not exist, enterprises have made progress in adapting their disaster recovery planning for company-wide coverage, with less and less of the fiefdom mentality. What is less clear is the degree to which organisations have also thought about the “domino” effect; instead of one risk with simultaneous multiple impacts, the domino effect concerns a risk with a particular impact that exposes another part of the organisation to a second risk and impact, leading to a third and so on.
The domino effect on disaster recovery may be dramatic – for example, flooding in an office that forces employees to “camp” in another office of the company across town, where IT staff have to work round the clock to get passwords and user profiles created, and get so busy that they fail to notice that network access to a strategic web server for e-commerce has failed, and so on. Or it may be insidious – poor quality inventory systems that gradually lead to lost orders, clients who switch to another supplier and excess inventory piling up in the warehouse.
It’s a problem already known to software developers. Because code for computer programs branches out at different points, they’ve developed testing techniques to predict and correct problems when there are multiple possibilities of “impact” each time a “domino falls over”. For effective disaster recovery at an organisational level, the answer may be to use similar modelling and simulation techniques – still using software as a tool, but this time using it to simulate domino effects between different functional elements in an enterprise and to test for problematical situations. Who knows, perhaps there’s a start-up somewhere working on such a solution right now.