IBM Systems Magazine, Mainframe - January/February 2018 - 33
SPONSORED ADVERTISING CONTENT
While the recovery itself is bottom-up,
the BC/DR plan itself should be
different from what you had
at the primary location. The
recovery may include OSes
and device drivers unique to
the new equipment. The use
of VMs might help hide some
of those differences, but now
isn't the time to figure out a
4. Human success factors.
Don't just focus on the
technological aspects. Also,
look at what I call my "five
Cs:" Command and control; communication and
and network connectivity;
contingency; and counseling.
Your staff may be scattered,
with some at the primary
location, at the DR facility or
somewhere else altogether.
Two metrics are used to
measure DR: recovery point
objective (RPO) and recovery time
objective (RTO). The technology
employed determines the RPO.
This is the time from when the
data was backed up to the time
the disaster happened. Backing
up to tapes once per day represents a 24-hour RPO. Mirroring
data to flash and disk located at
the disaster facility reduces this
down to seconds.
The automation employed
determines the RTO. This is the
time from when the disaster happened, to the time your business
process is operational again. This
includes the time for management
to assess the situation, recover
the data, re-host the applications
and correct any partial or incomplete transactions. Depending on
how manual or automated your
recovery is, this can be measured
in days, hours or minutes.
Plan of Action
While the recovery itself is
bottom-up, the BC/DR plan itself
should be developed top-down.
Focus first on the business
process as a unit of recovery.
Let's take payroll as an example.
Payroll involves three applications:
gathering the hours each employee
worked, performing some business
logic such as calculating tax withholdings, and then printing checks
or sending funds electronically via
direct-deposit. It does no good to
only recover one or two of those
applications; you need all three to
For each business process, prioritize its importance after a disaster.
Be pragmatic, use categories like
gold, silver and bronze to rank
each and assign a desired RTO for
each category (e.g., gold business
processes need to be operational in
four hours, silver in 48 hours and
bronze within two weeks).
Identify the applications and
data required to support each
business process and the needed
server, storage and network
infrastructure. Can these run in a
cloud? Do you have what you need
at your designated DR facility?
IBM conference attendees in
1983 documented a standard
set of DR levels. The business
continuity tiers were ranked from
"least expensive, longest time to
recover" to "most expensive, fastest recovery," and have stood the
test of time (see Figure 1, page
34). Over three decades later,
these are still the standards used
for BC/DR planning:
Data Safe and Secure
Today's mainframe is just another
server in the data center, accessible like every other Windows*, UNIX*
or Linux* server. Not only are mainframe environments vulnerable to
malicious insiders, but also to external hacktivists and criminals. As part
of an ongoing disaster recovery
plan, organizations should perform
regular security assessments.
Security assessments can help
identify and prioritize mainframe
penetration risks, determine
whether the implementation
the potential impact and exposure
operations and reputation.
Security assessments help
prevent security breaches while
protecting critical customer and
corporate data in the event of
disaster. They help reduce risk by
implementing security policies and
SURFHGXUHVÃ7KH\ÃLQFUHDVHÃHIÀFLHQcies in managing and auditing
mainframe systems while enhancing
productivity, decreasing downtime
and aligning security resources.
Security assessments target penetration risks based on
industry-leading knowledge of
security server, enterprise and cloud
Detailed reports include areas
where policies, procedures and
systems are creating risk, along
with rankings of detected vulnerabilities and detailed instructions for
remediating security problems, and
meeting standards and regulations
in the future.
Brian has extensive experience as
a senior executive in marketing,
strategy and business development.
JANUARY/FEBRUARY 2018 // 33