|
by By Jan A.
Persson – CDP
I started DRP (Disaster Recovery Planning) work in the
late 1970’s. In 1985 I started my consulting practice with the main
services being just that – DRP. At the time I was relatively certain
that DRP would be good for 5 or 6 years. At that time certainly all companies
would have a plan in place. What I’ve found is that not only are
many companies without a good plan today, but the field is actually expanding.
I see no end. I see constant new opportunities to implement recovery plans
and strategies for the ever increasing IT arena.
How It Was
In the "Early Years" (1980-1985) of DRP
it was lucky to get anyone outside of IS (Information Services) to recognize
the value DRP. If you had your backups stored offsite and some sort of
written document (i.e. a Plan) you were doing well. A Cold Site or Hot
Site contract (or agreement) simply put you at the head of the pack. The
business leaders had to at least say they understood the importance but
to actually spend money or take their time was definitely outside the
norm. There were some (a few) exceptions. The Banking industry was beginning
to be regulated and DRP was always an audit issue. Also, some companies
that experienced an actual disaster or "Near Miss" moved ahead
faster than all the rest.
Hard to believe you say? Not really.
Consider where we were in 1981. The "Mainframe" did the processing.
Some applications had on-line modules, but the bulk of the real processing
was done in "Batch" at night. CRT’s running CICS were available
but one terminal (workstation) for each employee was a long way off. Customers
still ordered through Order Entry Department, orders were shipped from
"Hardcopy" documents, and there were still a lot of people around
who "Knew" how the systems worked manually. Finally, key company
executives, let alone the CEO, weren’t involved hands-on with system
information via on-line terminals.
What Happened
How things have changed! Now, automation is a way
of life. All company areas rely directly on the availability of current
systems information and functions. IT in fact now runs how the company
works.
Just
consider a few facts:
- Order Entry is done on-line without much of
a Paper Trail,
- Manufacturing relies on computer generated JIT
Planning
- ERP (Enterprise Requirements Planning) is with
us
- Legal contracts bind customer service levels
with penalties for missed targets
- Tax and financial reporting is filed and distributed
electronically
- Whole companies communicate and actually do
business using telephony, email, Internet, Intranet, etc.
- Sales statistics are available to the field
in real time
- Financial reporting is consolidated from each
source location automatically
- Suppliers are required to utilize computer based
systems (EDI, XML, etc.) to
supply critical production parts
- ECommerce has expanded the sales opportunities
world-wide
- Distributed Systems abound (Client Servers are
routine)
- EUC (End User Computing) also abounds
- Networks (LAN, VAN, WAN, etc.) literally are
everywhere
- And a whole lot more
What hasn’t necessarily kept pace is the prudent
expansion of DRP.
What
Should be Done?
It’s a real good idea to take an assessment
of where DRP is. This involves a fairly straightforward inventory of locations
that use computer systems to conduct normal business. It turns out that
this is most locations. No surprise there!
A simple Matrix approach works well
for this. The left side of the matrix is simply the list of all locations.
The top is a rating of what DRP is in place. It can vary from "Tested
DRP" to "Nothing in Place". In between can be: "DRP
Started", "DRP Out of Date", etc. The point is to identify
where the are holes in the DRP. This then gets back to the "Prudent
DRP" concept. Has it kept pace, or, have you been standing still?
So, What's the Issue?
The issue is really a fair assessment and "Management
Awareness" communication. This is what separates the men from the
boys. It is all too common to simple identify the holes in the matrix
but not fairly communicate it in terms of risk (i.e Business Exposure).
For some reason, no one wants to be the messenger of bad news. Yet, that’s
really a part of the DR job.
In the end, Management needs to clearly
understand the DRP capability. Once understood, they can elect to either
spend money to fix the problem or choose not to. Either decision is fine
as long as they do it with full knowledge of the consequences (i.e. business
risks). What seems to be the case today is that if "Management"
understands the exposure (Holes in the Matrix) they approve the decision
and funding to move ahead.
Final Comments
It’s a question of survival. And lets face
it, DRP plays a major role in survival. It is my belief that DRP has moved
well past the early days (last 15 years) of the rather mundane tasks of;
write a plan, backup the data, and go to the Hot Site and test once a
year or even less often. We should be on the lookout for "Holes in
the Matrix" and be prepared to move forward. We need to ask the difficult
questions, stick our nose in when we sniff a problem, and be ready to
challenge anyone who isn’t willing to move forward. DR is no place
to stand still!
Jan Persson – CDP,
has worked in the I.T. field since 1967. He began his disaster recovery
involvement in 1980 and in 1985 started his own disaster recovery consulting
practice, PERSSON ASSOCIATES. He has written and/or audited over 200 DR
Plans, worked for and with the 3 major disaster recovery firms, conducts
DR training seminars and workshops, and continues to take an active, hands-on,
role in DR activities in all size shops and environments.
Copyright (c)2003, Jan Persson, CPD. All Rights Reserved.
|
