Process 2: Identify and Map Services

 

Service maps are used throughout the IT organization to clarify the dependencies between SLAs, OLAs, technologies, customers, and the impact to the service delivery. They identify the resources necessary to deliver a service described in the service catalog, who delivers that service, and who consumes it.

A service map represents a service from the perspective of the business and the user. It is divided into five sections:

  • Customers. A categorized list of individuals and groups who use the service.
  • Hardware. The hardware platforms necessary for service delivery.
  • Applications. The operating system(s) and other applications the service requires.
  • Settings. The configuration settings necessary for the service to function.
  • Internal/external services. The components that help ensure availability for the service.

Activities: Identify and Map Services

The following table lists the activities involved in this process. These activities include:

  • Identifying services and owners.
  • Identifying key customers and users.
  • Reviewing, classifying, and categorizing key service component groups and service owners.
  • Publishing a service map.

Table 6. Activities and Considerations for Identifying and Mapping Services

Activities

Considerations

Identify services and owners

Key questions:

  • What does the organization call the service?
  • Who from IT is accountable for the business service? Who is the business representative for the service?
  • Does the IT service representative know the IT owners of services dependent on this one?
  • What are the main IT core infrastructure services and who are the owners? Does the business understand the importance of core services such as networking, hosting, messaging, collaboration services, security, provisioning, and Web services?

Inputs:

  • Existing responsibility matrices—for example, Responsible/Accountable/Consulted/Informed (RACI) charts
  • List of business applications and services
  • List of infrastructure services
  • Configuration management system (CMS)
  • Service portfolio; service catalog

Outputs:

  • List of services and service owners, including business and IT representation
  • List of all IT-dependent service owners
  • RACI matrices

Best practice:

  • Use RACI, CMS, Business Continuance/Disaster Recovery (BC/DR) plans to identify services and owners you might otherwise miss.

Identify key customers and users

Key questions:

  • Who are the main users of the service?
  • Is there a cyclical nature to the use of the service? For example, is usage heavy during certain events or times of the year?
  • What is the business context? For example, is it used by legal, financial, sales and marketing, or research and development?

Inputs:

  • Service owners
  • Service Desk and incident management data for this service to show who uses it

Output:

  • Comprehensive list of key customers and users

Review, classify, and categorize

Key questions:

  • What are all the components of the service? Who owns each component? What are the software and hardware components? Are certain external components hosted or owned outside the organization?
  • What level of detail is needed to be useful? How many and which component services should be mapped to the customer-facing service?  
  • How are the components currently categorized in the CMS?
  • How are the components currently categorized in the incident management system?
  • Are the components defined as services? If not, can they be defined that way?

Inputs:

  • CMS
  • Incident management
  • Service catalog
  • Data flow diagrams

Outputs:

  • List of component classifications and categorizations that are in alignment with the CMS and incident management
  • Initial draft of service mapping illustration in Microsoft® Visio®
  • Initial draft of service mapping table in Microsoft Excel®

Best practice:

  • Create a tool that maps user descriptions of incidents to the IT services that address them (it can be as simple as a glossary in a Microsoft Word document on a shared server).

Publish service map

Key questions:

  • Who needs to use the service map? What other processes are dependent on the service map? (For example, incident management, problem management, and service monitoring and control will all need to have an end-to-end view of the service, whereas end users might need to understand only the high-level data flow.)
  • How will the service map stay current?

Inputs:

  • Service catalog
  • Service portfolio

Outputs:

  • Service maps presented in visual form (see Figure 2)
  • Service maps that identify owners of each service, including the dependent services

 Best practice:

  • Create an infrastructure service map that exposes the core services that support all other IT services. Technical services might include directory, messaging and collaboration, file management and backup, network, printing, desktop, and server farms. Other service types could include provisioning, support desk, software update, patching, and compliance reporting.

Figure 2 shows a sample service map.

Figure 2. Sample service map

This accelerator is part of a larger series of tools and guidance from Solution Accelerators.

Download

Get the Microsoft Operations Framework 4.0

Solution Accelerators Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions