Disaster Recovery Journal, Fall 2009

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 disaster.

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 value proposition.

... 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.

u Who must be notified before shutting down a database?

u Which vendor contracts can be eliminated?

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 worm? u What if your hosting provider lost power to your servers? u What if a certain expert employee leaves?

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 sponsorship.

Share Your Research

Don’t be strictly an information consumer, be an information maven like Malcolm Glad well describes in his excellent

v

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.