dependencies from process to
application to server. Some trace
as far as power infrastructure such
as power supplies, circuits and
generators. A company highly
sensitive to IT failures would logically want greater visibility of the
IT dependency configuration to
aid planning and response to interruption.
If your BC/DR effort has a
large IT focus, consider using your
dependency model of IT resources
as a high level blueprint of your
datacenter’s infrastructure. If you
have taken the dependency model
as far as servers, software and people, you
should have high level diagrams useful in
identifying IT resources needed to rebuild
your datacenter in case of a large scale
At the beginning of this article I promised to describe a strategy for getting buy
in and sponsorship of this effort. If you
read many of the how-to approaches to
executing a BC/DR planning project one
admonition you will find is to “get executive sponsorship” or “get buy in from the
business units” early on. Unfortunately
sponsorship and “buy in” are not something you can simply ask for. It must be
earned and it’s earned by delivering on a
... as you gather information about
each business unit’s requirements
and the IT department’s infrastructure,
compile and publish that knowledge
back out, returning value to those who
u Who must be notified before shutting
down a database?
u Which vendor contracts can be
Demonstrate Value Early On
Here is how you can demonstrate value
early on to those you engage for information. There is a “digital divide” that slices
between business managers and IT workers in most companies that creates communication challenges between the users
of IT services and the IT service providers.
IT staff work heads down among their
peers with business managers doing the
same amongst theirs, coming together in
fair weather with smiles and handshakes
on a new project launch, or fear and finger
pointing when something blows up.
This “digital divide” is both a challenge
for BC/DR planners and an opportunity to
provide early value back to your participants by communicating key information
between the groups.
For instance, these questions can only
be answered be reaching across the digital
divide for information:
Let’s look at the first one:
How does a database administrator
(DBA) determine who will be impacted
by shutting down a particular database?
Experienced IT workers are gun shy
about shutting things off to perform service. Tracking down the affected parties to
notify can be a hit or miss effort without
a clear understanding of everything that
depends upon that database. If the BC/DR
specialist makes his or her research available to the DBA, the DBA can trace the
dependencies and determine who to notify
regarding the planned outage. This provides value early on, and goes a long way
to getting buy in from the DBA.
Now let us look at it from a business
unit’s perspective such as finance:
If the financial managers want to understand why certain vendor support contracts
are in the budget, they can refer to the
dependency diagrams to understand how
that vendor’s contract supports the business’s software or services and ultimately
the dependent business processes.
Notice how neither of these uses of the
dependency model are the primary goal of
the BC/DR effort yet they provide value to
participants early on.
Without short term value feedback, the
experts you interview are simply throwing
their time and information over a wall and
getting nothing in return.
book “Tipping Point.” Knowledge
is power, and the maven’s power
comes from sharing knowledge.
So as you gather information about
each business unit’s requirements
and the IT department’s infrastructure, compile and publish that
knowledge back out, returning
value to those who provided it.
Cross pollinate information
between business units. Like the
honeybee that benefits each flower
and itself with nectar, you distribute
key information to each business
unit, and reward your own efforts
with a high quality understanding
of the business’s dependencies. Now you
have your data and method for getting buy
in via a compelling value proposition that
executives will continue to sponsor.
Simply arguing that your mission is to
save the company from disaster would be
a trump card for participation in an ideal
world. But remember this is the real world,
and although your mission is noble, that
rally cry alone may fail to muster the
troops. But visible progress and early
value from dependency models can help
build momentum towards success. Win by
demonstration never by argument.
When you succeed in creating a comprehensive dependency model for your
business, you can then perform what-if
impact analysis, such as:
u What might happen if certain servers
were brought down from a virus or
u What if your hosting provider lost
power to your servers?
u What if a certain expert employee
The power to answer these questions
comes from understanding your company’s dependencies. Building a comprehensive dependency model is a method
for connecting business processes to IT
infrastructure revealing IT related risks.
The knowledge gained can be shared
throughout the company, giving the BC/
DR planner greater visibility, buy-in, and
Share Your Research
Don’t be strictly an information consumer, be an information maven like
Malcolm Glad well describes in his excellent
Daniel Evenson, C TO of Pathway Systems,
has worked in the IT industry for more than
15 years and has a very broad knowledge
base. He is an expert in the modeling and
simulation of complex IT environments.
50 DISASTER RECOVERY JOURNAL FALL 2009