Fig. 4
the order-taking business process be
impacted? Yes; so we know order-taking needs WebSale. Try the converse: If
order-taking were failing, would WebSale
be impacted? No. The same questions
applied with order-taking and order-shipping should reveal there is no dependency
between them in either direction. Take the
time to digest this way of depicting the
relationship for it’s a core concept upon
which the comprehensive dependency
model is built.
Notice how we modeled dependencies
from one process to another, and from
process to IT application using the same
approach. In dependency modeling we
care only about the dependencies between
things. It makes no difference what the
things are; processes can depend on processes just like processes can depend on
IT services, or even people for that matter.
By studying a complex system (your company) with that in mind, it reveals exactly
the information needed to perform a business impact analysis. Although a more
traditional approach is to study the system
in a data-centric fashion via inputs and
outputs, that technique is better suited to
BPM (business process modeling), a more
involved effort typically used for process
re-engineering, not risk analysis.
Think Dependency,
Not Data Flow
As we perform discovery of IT systems through interviews with IT experts
or by reviewing existing documentation,
we also find much of the information we
need is presented in a data-centric form.
The “data flow” diagram is a common way
of describing the inner workings of an IT
system since it’s useful to the technicians
who deploy and support those systems, but
it’s not quite what we need for dependency
modeling. One of the recurring challenges
faced in modeling a system’s dependencies is converting the data flow mindset to
a dependency mindset.
Ask an IT worker to explain the e-mail
system and they will likely describe how
email data itself flows through the various servers and services running on those
servers. Figure 3 is a simplified representation of a data flow diagram detailing just
that; email data flowing from an external
mail server through a company’s spam
filter, Exchange server, and ultimately to
the email client application Outlook on a
desktop.
Since we are seeking to understand
which business processes depend upon
these services and why, let us reinterpret
this as a dependency model in conjunction
with the business processes of sending and
receiving email both internally (between
employees) and externally (employee to
non-employee). Unless you work directly
in IT on these systems, you may need
help converting the data-flow view to a
dependency view. Staring at confusing,
data-centric IT diagrams often will leave
you bewildered. Work with the IT experts
instead, and coach them into describing
the system’s dependencies. The e-mail
administrator might then describe subtle
differences in dependencies for using
e-mail internally vs. externally as Figure
4 reveals.
Now you can see how this company’s
overall email capability would be impacted
by a failure of the Hercules server by
visually tracing the dependencies from
Hercules to the left, identifying affected
business processes. This inspection reveals
that e-mail communication with external
parties should be unavailable; however,
internal e-mail should remain unaffected.
Apply this approach to understand and
describe the dependencies of all business
units. List all important business processes
and trace their chain of dependencies to
other processes, people, vendors, and IT
services, etc. In doing so, you will build a
comprehensive model of your company’s
threats to business and produce a body of
correctly structured information to perform business impact analysis.
This approach to understanding your
company’s risk by researching and documenting dependencies is no small task for
the BC/DR specialist, but it is a consistent,
repeatable process that can be adjusted to fit
your needs. Start with high level business
processes and IT systems and re-adjust the
model as you glean greater details through
interviews with IT and business units.
BC/DR research and documentation
efforts vary in how deeply the dependency analysis descends into the IT infrastructure. Some organizations may link
business processes only as far as the busi-ness-facing IT system or application level
and not extend the dependency tree any
further. Other companies may go much
DISASTER RECOVER Y JOURNAL FALL 2009 49
