Service Maping

Introduction

This document is intended to introduce the content, structure, development, usage, and benefits of service maps. It will:

• Show you a service map. It will show you an example of a complete service map, including the typical content and structure.

• Demonstrate how to build service maps. It will provide detailed guidance on how to get started building a service map as well as considerations on how to take a programmatic approach to mapping services in your service delivery organization.

• Suggest how to use service maps. It will provide examples of how service maps are used, by whom, and why.

Intended Audience

This document is intended for those who have a basic understanding of Microsoft® Operations Framework (MOF) concepts and terminology and who are familiar with Microsoft products and technologies. While this prerequisite knowledge is not essential to comprehend service mapping, it is helpful.

What Is a Service Map?

A service map is a graphical display of a service that illustrates the various components upon which successful delivery of that service relies. These components generally include hardware, software, and configurable settings or roles, as well as customers and other services. A Microsoft-developed best practice, a service map is a communications tool that illustrates the “what” of a service (its components and their relationships) as a basis for managing the “how” of a service (how the service is delivered and controlled to ensure expected availability, capacity, security, and manageability).

Service maps are useful in documenting an environment because:

• They present a service-centered view of the environment, organizing technical capability in business-oriented terms.

• They more readily facilitate understanding of complex systems and component dependencies than text-based documents for both technical staff and customers.

How Are Service Maps Used?

To illustrate the potential uses of a service map, consider the example of a collaboration service built with Microsoft SharePoint®. In this example, the SharePoint collaboration service is critical because it supports several key business processes. As a result, within its service level agreement (SLA), the service delivery organization has committed to a minimum level of availability for the service with the customers of the service.

To effectively manage this service requires adequate knowledge and understanding of the components of that service. Consider these scenarios:

• You are a Service Level Manager being asked by the business for higher availability. Will the existing components support this level of service?

• You are a Configuration Administrator trying to assess the impact of a change to a hardware component within the service. How will you predict the upstream and downstream impact?

• You are a Problem Analyst attempting to diagnose the root cause of a problem related to the service. How do you efficiently trace the cause downstream?

• You are a Test Manager developing a testing plan for a new release of the service. How do you identify all the components you need to test?

To help answer these questions, you could potentially reference component-level technical documents, but they might not clearly illustrate interrelationships. Or you could probably get good information from the service delivery teams responsible for the relevant components, assuming you know the correct teams.

A service map of the SharePoint collaboration service would be valuable in all these scenarios. With a well-defined service map, you would be able to quickly plot the major components underpinning the SharePoint collaboration service to help users answer the above questions. The map might not answer every question, but it should help point you to relevant component-level technical documentation and to the right teams.

Figure 1. A service and its component dependencies

Consider these scenarios again, this time equipped with the service map in Figure 1 for reference:

• You are a Service Level Manager being asked by the business for higher availability. The service map will help you identify the key components and dependencies that require investigation so you can then consult the proper teams to make a clear determination about the feasibility of the request.

• You are a Configuration Administrator trying to assess the impact of a change to a hardware component within the service. You can reference the service map to identify the relevant upstream and downstream components and the teams responsible so that you can accurately predict the impact.

• You are a Problem Analyst attempting to diagnose the root cause of a problem related to the service. You can reference the service map to trace the root cause of the problem downstream and then involve the appropriate teams in the diagnosis and resolution process.

• You are a Test Manager developing a testing plan for a new release of the service. The service map will help you identify the components to include in testing and the teams you’ll want to involve in the testing process.

Service Maps: What They Are and Are Not

A service map is:

• A valuable reference tool at all levels of a service delivery organization and across all phases of the service management lifecycle that demonstrate relationships and dependencies better than many other documents, such as architecture diagrams and configuration specifications.

• A communication tool, the value of which is to connect the user quickly with the resources—people and information—needed to make the best decisions.

A service map is not:

• A replacement for other key reference documents such as architecture diagrams and configuration specifications.

• A graphic representation of a configuration management system.

• A replacement for a service catalog.

As organizations become better at developing and using service maps, they may create more sophisticated service maps that incorporate additional information and functionality, making them more than reference tools. However, it’s

...