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 important to note that the fundamental purpose of a service map is orientation—and they can provide great value doing this alone.

Service Map Content and Structure

This section illustrates the basic components and construction of a service map.

Content

As illustrated in Figure 1, service maps are graphical depictions of a service decomposed into its smaller component parts. Most services can be decomposed into the five component categories, or “streams,” shown in Figure 2. (Note that Figure 2 illustrates the component categories, but not the relationships among them, which will be described later.)

Figure 2. The five component streams

These five streams are likely to capture most information on the components required to manage a service, although they may be modified or appended to best suit the needs of a particular service or organization.

Table 1 outlines the typical components within each stream and the potential data sources for each.

Table 1. Components Within Service Map Streams

Stream Typical components Potential data sources for this service map stream Example components

Software All software associated with a given service including the core application itself, any supporting or dependent applications, network and control software, maintenance software, and versioning information. Software data usually comes from service catalogs or software portfolios. This also includes any dependent software related to the service being mapped. Windows Server® 2008 SP2 x64

Hardware All servers, network devices, storage equipment, and desktop PCs required for a service to function, including model and configuration information where appropriate. Hardware data can be identified through the configuration management system (CMS) or other similar sources of configuration data. HP DL 385 G2

Stream Typical components Potential data sources for this service map stream Example components

Services Other services upon which the primary service depends. Upstream services feed required input to the service in question, while downstream services are fed output from the primary service. For example, a service like Exchange or SharePoint will typically rely on several downstream services such as Active Directory®, Backup, and Service Desk. Service catalogs and service portfolios are a good source for this type of data. DNS and Help Desk/Call Center/Level-1

Settings The configurable settings needed for the service to function effectively. Configuration diagrams are an excellent source for setting data since they typically include details about settings or roles of other dependent equipment such as server or network devices. Server roles such as Index Server, Query Server, and Database Server

Domain authenticated to gateway IP address

Customers The consumers of the service and relevant information about them such as department, location, and means of contact. This could include specific business units, geographical regions, or classes of users (such as “Executives”). Design packages created during requirements analysis or the design phase of the service management lifecycle are excellent sources of customer data. Service owners and the service level manager may also be able to provide data about customers. Accounts payable department

Structure

Building on the SharePoint example, Figure 3 represents a complete service map for the SharePoint collaboration service. The brainstorming diagram

...