nDATA PROTECTION
Connecting Business
Process, IT Infrastructure
By DANIEL EVENSON
On June 29th of 2009, the cloud hosting vendor Rackspace xperienced a power failure which brought down customer servers in their Texas datacenter. Rackspace
estimates this will cost them up to $3.5
million in customer service credits alone.
[See the Rackspace account of the outage
on page 32.]
Even the popular singer Justin
Timberlake was impacted by the outage,
bemoaning the failure to his fans via
Twitter. Increasing dependency on IT services make such failures more common.
Understanding these dependencies and
their potential impact is a large part of the
BC/DR planning effort.
In this article, I’ll explain how to prepare for conducting business impact analysis via an approach called dependency
modeling, as well as demonstrate how the
BC/DR specialist can develop two key
success factors early on: business unit buy
in, and executive sponsorship.
Dependency Modeling
In dependency modeling we trace and
record all critical dependencies within
a business to build a model that comprehensively documents that business’s
unique dependency configuration forming
the foundation for conducting a business
impact analysis. This helps you develop
good strategies to manage risks to business operations, especially those due to IT
failures.
First, let us look closely at a visual
approach to representing dependencies
since a consistent visualization model
enables members of various business units
and IT to discuss and build upon the same
information. A picture is worth a thousand
words or, in this case, a diagram beats a
spreadsheet.
Say we have identified three business
processes called product-sales, order-taking, and order-shipping. Since we know
that product-sales requires both order-taking and order-shipping, to represent
this visually it should look something like
Figure 1.
The green lines between the processes
represent the dependency, and the direction is important. It implies that product-sales requires order-taking and not the
other way around.
Taking the analysis one level further,
we might ask what order-taking needs.
Perhaps customers purchase products via
an application called WebSale. We add
the additional dependency like shown in
Figure 2.
To properly identify the dependency
and its direction ask this question: If the
WebSale application were failing, would
Fig. 1
Fig. 2
Fig. 3
48 DISASTER RECOVERY JOURNAL FALL 2009