On June 29th of 2009, the cloud hosting vendor Rackspace experienced 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.
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 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 business-facing IT system or application level and not extend the dependency tree any further. Other companies may go much 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.
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:
- Who must be notified before shutting down a database?
- Which vendor contracts can be eliminated?
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.
Share Your Research
Don’t be strictly an information consumer, be an information maven like Malcolm Gladwell describes in his excellent 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:
- What might happen if certain servers were brought down from a virus or worm?
- What if your hosting provider lost power to your servers?
- 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.
Daniel Evenson, CTO 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.
