Over at UKRC a couple of weeks ago I I spoke to a number of folk about the technology behind a ‘Business Continuity’ solution. The technology involved was indeed a fine solution for Disaster Recovery – but that is not the same as Business Continuity. Those conversations have prompted me to begin a series of notes on Business Continuity beginning with this one.
So what is the difference between DR and BC? I’ll try to put it into the context of the IT services in a mid-large sized hospital. A typical mid-sized hospital might have IT services delivered through a Data Centre (DC) in a secure location on campus. A great deal of money is spent minimising the risks associated with this DC – with carefully planned air conditioning, UPS, backup generators, physical access control and the like. Lets say for the sake of argument this DC contains 100 servers, along with assorted networking equipment. The backup strategy employed is an aggressive one – full backups are taken every 12 hours and taken off-site, with a monthly and quarterly recovery testing plan. Even that level of organisation is a major challenge.
The original DC is unusable (buried in debris), so some amount of ground work is needed to move power supplies to an alternate location (lets say there is one handily available). Ordering, shipping and commissioning all of the servers and networking equipment could take a 2-3 weeks (optimistically). Mobilising software vendors to install and make ready for use the software might be another week or two. AS a Disaster Recovery Plan, this is clearly unacceptable – so we’ll assume a prioritisation exercise is performed on a quarterly basis to ensure main systems are back online as soon as possible. With a good plan, good backups, and skilled workers, the first 10 services might be back online within 5 days, with the stragglers taking up to 3-4 weeks longer.
On one hand, this is a slightly pessimistic example. Data Centres can be quite resilient to such risks. And the evolution of SAN and Virtualisation options complements the traditional backup mechanisms well. But not all data centre facilities are created equal, the risk remains and the Black Swan event always looms. More about the Black Swan in a later note.
So the disaster in this case has been recovered from, but there is nothing mentioned so far about Continuity of Service. How did the core business processes (in our case, patient care) continue while this DR was ongoing? Many things might have happened – alternate ‘cloud’ solutions could be deployed. Many processes may well have reverted to manual pen-and-paper for the duration. A local ‘bank’ staff agency may well have deployed a number of additional staff to cope with the confusion. Having these options available for whatever ‘disaster’ befalls a hospital – not just in relation to IT – is where Business Continuity Planning is important, and different to DR. BC is as much about what *else* happens while the process of DR is ongoing.
Each of these coping mechanisms required something to happen in good time. The cloud solution may require an existing account with provision for sudden upscaling. Reversion to manual processes may require maintenance of stock of otherwise redundant stationary, and an existing relationship with the bank agency would certainly be a helpful lubricant. These can all be planned, communications plans drawn up to allow speedy access to the right people, a small room set aside to store old-style pre-OrderComms requisition slips, to be prepared, a room allocated to be the coordination base for all of these coping mechanisms.
A BC Plan requires decision makers (at an appropriate level depending on the circumstances) being mobilised, and being empowered with skills, resources and tools to keep the core business processes operational. Information Technology is not a core business process in Healthcare – it has become one of the most important contributing services but still tangential. Business Continuity is about the Business, not the contributors.
While there is an established framework for maximising the effectiveness of Business Continuity Planning the first step is to appreciate the difference between DR and BC.
Next up: Disaster Tolerance, the Technology Stack, and the Cloud.
1 Comment to “Business Continuity Planning in Health IT”
Latest from the Blog:
- High Availability
- Lessons learned
- Open Source
- PACS General
- Project matters
- Martin Peacock on Virtual Servers and PACS
- Edward Mangiola on Virtual Servers and PACS
- Globalstorage on Business Continuity Planning in Health IT
- Martin P on Window/Levelling in a browser – CANVAS or server-trips?
- Martin P on 3D can be a dangerous game