Some organizations have great IT Service Continuity plans--e-commerce companies like eBay, hospital IT shops, and the military, for example. Others don't have such great continuity plans, and only prepare plans as a response to recent events e.g. Hurricane Katrina. I'm wondering if it's possible to "make a case" for service continuity. I've thought in the past that organizations forget about service continuity at their peril--one day there will be a disaster that strikes, and you may not be able to recover. However, now I'm wondering if the businesses who need IT Service Continuity the most just "feel it in their bones." They KNOW they need service continuity, and there's not much need to justify the expense. Or perhaps, the difference is that there are some organizations that have actually endured the disasters (e.g. eBay's 14-hour outage in 1999) and they are acutely aware of the risks. Or perhaps, for these organizations disasters are much more likely to occur. There is always a fine line between availability management (keeping a service available, and taking steps to make it available when it goes down) and IT Service Continuity management (restoring a service after a disaster). I wonder if the organizations with better IT Service Continuity capabilities just tend to have disasters to blame for a higher percentage of their availability issues. All that said, I don't know if it's possible to "make a case" for service continuity. If a University or business doesn't feel a constant pressure to ask what would happen in a disaster, then they probably won't want to pay for service continuity. As long as the service levels are documented maybe that's just the end of the story--and everyone agrees it would take several weeks to bring up certain services. Individual site contributors are solely responsible for the content of this web site.
|
|||
ITSCM...it depends!
Great topic and question! As with so many things, the answer is really that the case for ITSCM depends on how wisely the process is scoped.
It'd be difficult, I think, to make the case that no ITSCM is warranted. Without going through something like a Business Impact Analysis, how would you know? The key, again, is gauging efforts prudently (at every step) to match objectives and resources. In other words, scoping the process appropriately.
ITSCM can be very simple or very elaborate.
In the vast majority of environments I've come into contact with in 15 years of doing IT, the pattern is to overspend on recovery technology while underservicing the process side of things. The net result is usually expensive and, in many cases, simply ineffective protection against business disruption. Costly redundancy solutions are purchased, but because processes are lacking, the solutions are not tested adequately, human roles in recovery/continuity are left to chance, invocation criteria are not defined, service changes are not incorporated over time, etc. The result, again, is lots of spend coupled with a false sense of security, and (sometimes) an unpleasant surprise when something actually fails.
ITSCM efforts, like all process efforts (why not all IT efforts?), do best when a Pareto Optimality approach is used to pursue them. At base that just means choosing the top few process-things one might do to achieve maximum benefit.
There are plenty of examples (some spectacular!) in which ITSCM efforts have been either under or over scoped. Neither side of the error curve works well. The damage done by under-scoping typically surfaces acutely when an actual disaster strikes. Over-scoping, by contrast, results in chronic overspend and, as I mention earlier, often still results in specacular disappointment if that spending has been inappropriately biased toward the technology side of the solution.