Technical Dependency Analysis

Hi, I’m Kevin Harris, Principal Program Manager with Microsoft’s Enterprise Business Continuity Management (EBCM) team. This blog entry accompanies my video on a key component of our business continuity methodology – the Technical Dependency Analysis or TDA.

The Business Impact Analysis (covered in an earlier blog and video) is our process driven engagement point that provides both an evaluation process criticality, using a standardized list of criteria to qualify and quantity the risk of an unexpected disruption. We engage directly with each business unit to document the anticipated impacts, which then substantiate the recovery goals for that process (in terms of recovery time objectives and recovery point objectives). Our implementation at Microsoft prioritizes those business processes that meet the company’s criticality standards. These “critical” processes then undergo a dependency analysis that includes non-technical items (such as people, internal or external dependencies) as well as technical dependencies (such as Line of Business applications, middleware, infrastructure, etc.).

For each technical dependency that the business identifies as essential for recovery, we conduct a detailed technical dependency analysis (TDA). The TDA is important because each application identified by the business is really a complex web of technical dependencies, which usually have additional technical components, secondary and/or tertiary dependencies that the business is unaware of but are essential to recovery of the Line of Business application. Without this important TDA phase, some technical dependencies that are working “behind the scenes” may be missed, which could prevent recovery of that particular business process or function.

The TDA is critical to the successful implementation of a business recovery strategy. Each layer of each technical component needs to have its own recovery time objective that allows the successive layers ample time to recover and still meet the overall process recovery time objective (RTO). The TDA also assists us with identifying single points of failure and tracking critical technical assets.

As I mention in the video, the TDA provides an “end-to-end” mapping or a blueprint of a technical environment. This information helps business continuity or disaster recovery teams to:

• Understand the current recovery capability of a technical dependency
• Create strategies that take all aspects of technical recovery into account
• Gain insight into capacity planning for shared infrastructure elements.

In addition to BCM, the data collected during the TDA has benefits that extend well beyond a BCM program. For example, periodic review of an “end-to-end” process can result in process and quality optimization. These technical “blueprints” provide holistic views for enabling effective service management, managing a service catalog, as well as modeling opportunities for new architecture designs or system deployments. Organizations can also use this information to plan for or evaluate risks associated with a specific element of infrastructure as I mention in the video with the data center example. The information asset from the TDA also helps crisis management teams understand business impact of threats (e.g. flood impacts to a data center).

Our broader vision is to build an information asset that provides value to and is maintained by a broad stakeholder community. One of the single most important best practices associated with any BCM program is keeping the data and plans current; the TDA is no exception, so it is important that refreshes of the data occur regularly. Organizational discipline with Change Management practices and BCM maintenance policies are essential to ensuring the information stays relevant and disaster recovery capabilities meet stakeholder expectations.

-Kevin Harris
Principal Program Manager, Enterprise Business Continuity
Microsoft Information Security