One question I’m frequently asked is “What is Service Mapping and what will it do for my organization?” While some applications on the ServiceNow platform can be easily summarized in a few sentences, Service Mapping deserves a deeper conversation to really illustrate the value that it brings. There is sometimes confusion with the purpose for building Service Maps, which leads to disappointment if a customer is expecting something that it was never intended to do. The opportunity to TA the Service Mapping Pre-Conference training at K17 earlier this month gave me the chance to talk to the instructors, TAs and students to compare their real-world experiences from their involvement on Service Mapping projects. Hearing perspectives from both customers and those responsible for delivery on these engagements, and drawing from my own experiences, the thing that really stood out to me is the importance of clearly setting the expectation on what Service Mapping is, and what it is not.
First, I would like to start by pointing out a few things that Service Mapping is not.
- It is not a monitoring solution. One misconception about Service Mapping is that it will provide a visual representation of your infrastructure on a single pane of glass, and when a device fails, it will immediately appear as an alert on the map. While it’s possible to leverage Event Management in conjunction with a monitoring tool to provide this sort of visual feedback in real-time, this is not the purpose of Service Mapping as it stands on its own. When discovery is run on a service, it will identify changes as well as highlight hosts that are not accessible, but the discovery process is not an activity that runs continually. It is typically scheduled on a periodic basis, and in some cases, may take an hour or longer to complete discovery, depending on the size and scope of the service. This makes it difficult to rely on as a means of monitoring for real-time status of the environment.
- It is not a turnkey, zero-config solution. Service Mapping contains a large number of out-of-box patterns that can discover applications, however in many cases there is still a need to perform some level of customization to these patterns to capture the information specific to different environments. This may include parsing specific command parameters, configuration file paths, or other unique characteristics that deviate from a standard build. It does become an automated activity once the work to capture these deviations has been built into a pattern, but there is often some work needed to get to that point initially. Maintaining these patterns is then only needed if additional customizations or changes to the environment are introduced.
- It is not a map of servers, routers or other gear. ServiceNow CMDB provides dependency views to show how configuration items are connected based on relationships. For instance, when viewing a router, you see the router interfaces, the connected switches, the servers connected to those switches and what network adapters and storage devices are connected to those servers. Service Mapping is focused on how a particular Business Service is comprised of the different application components needed to deliver that service. For a very basic service, this might include a web server, the hosted web application, and the underlying databases. While it is possible to switch to a host view to see the hardware configuration items, as well as displaying network paths, the intent of Service Mapping is to provide the “service-centric” view of the environment.
Now that I’ve laid out a few things that Service Mapping is not, I would like to look at what it is.
- Mapping a service is collaborative and iterative. A common theme repeated by the instructor of the class was that Service Mapping takes a village, and it’s a very true statement. It’s rare to find one person with all of the knowledge required to map a complete business service. It will require input from the network, server, database, and application teams along with the business owners. This is after working with the security team to be granted the access needed to begin the work. Depending on the level of complexity of the service being mapped and inconsistencies across an environment, it may be necessary to re-engage some of these teams to progress through the mapping.
- A service map is a very useful troubleshooting tool. Once a Business Service has been mapped, in can be an invaluable tool for troubleshooting an issue impacting the service. If the service desk is receiving calls from users who are unable to access a particular service, the map becomes a reference for all of the configuration items that support the service, instantly narrowing the scope of focus for the recovery teams. Proactively, if a particular host is down, it is now possible to identify what services are going to be impacted. Integrating a monitoring tool with Event Management further enhances this capability.
- Service mapping provides a way to minimize risk. In addition to the visual aspect that characterizes Service Mapping, the underlying relationships that are formed between configuration items can minimize risk when planning scheduled maintenance using Change Management. By understanding the components that comprise a business service, it is then possible to prevent scheduling changes that could potentially impact the service.
This is not meant to be a definitive list, but are some of the key areas that sometimes lead to confusion around why an organization would want to include Service Mapping in their roadmap. By understanding these differences, it makes it easier to demonstrate to leadership the value that comes with implementing Service Mapping and ensures satisfaction after it is in place.
Once the decision has been made to use Service Mapping, there are some initial considerations and planning that need to be made leading up to the project kickoff. Looking ahead to my next post, I plan to highlight some areas that can help avoid delays or prevent roadblocks to a successful implementation.