The current Blackberry outage going on throughout Europe, and now the US, provides an opportunity to discuss two important Business Continuity Planning issues:
- Don’t rely on a single communications device
- Ensure you have processes for addressing the backlog
I remember immediately after the events on 9/11 people were touting how well their Blackberries continued to function during the crisis while all other communications tools were failing. Shortly after, it seems, everyone was running out and buying a Blackberry. I was not suggesting people not invest in Blackberries, but I was warning people that just because this particular tool was working in this crisis does not mean it will be the one tool working in the next crisis. One reason the Blackberry worked so well in 2001 was because so few people were using this device, the infrastructure that supported it was not being overburdened during the time of crisis. Blackberries rely on a different technology and different infrastructure that was not damaged during 9/11 – I was warning anyone who cared to listen (probably no one) that this might not be true during the next crisis. My point was not that Blackberries won’t always work, but that you should not rely on a single tool or technology for all of your communications channels. Lo and behold, we now find out that Blackberries are susceptible to network wide outages similar to other communication tools.
In the referenced article, Research in Motion is saying that they have fixed the underlying problem causing the outage but that the backlog of emails and text messages is delaying getting the service fully functional once again. This is a reminder to make sure that business areas consider the impact of the backlog during times of outage and have procedures in place to address the backlog once their systems are back online.
I have even seen instances when the inability to handle the backlog that would develop was the primary justification for establishing an RTO for some applications.
Procedures for handling the backlog (and, reentering lost transactions where the RPO is not, point of failure) need to be included in each department’s business continuity plan. For some financial based applications, this may include having to post date transactions to ensure they have the right effective date with them. For some applications that automatically generate the transaction date and time, this may require some additional programming or rebooting servers with different time stamps to ensure the proper entry date.
For all applications and business processes that are not immediately failed over, there is the potential for a backlog to develop. How you handle that backlog must be considered in the recovery and continuity plans.