Service Mapping To The Rescue


Gone are the days when it was hard to keep track of your assets and databases being located at different locations and you faced difficulty in accessing the same from a single point. In this era of technological advancement, tools like Service Mapping have come to your rescue. With the help of this tool, we improved the CMDB usability and visibility of configuration items to ensure quality incident, change, and management processes for a client. It also helped to point out where outages occurred and what was the impact of those outages to make better-informed business decisions.


A lot of different company’s environments use the same kind of business service map. There are quite some technicalities involved in this process to get the end result. These include challenges like as following:

  • Implemented Business Application’s entry point hosted on the load balancer device on which configured Mid Server was not able to retrieve the information from the load balancer and was not returning OIDs.
  • After the entry point, the business application has the web tier applications which are functional IPs and the mid server can only access through the management IP. The configured mid server was having issues connecting to the functional web tier IPs.
  • Some host devices that are already being discovered inside the CMDB table had duplicates that were creating the issues in Service Mapping because service map will get confused from the duplicates.


For this process of Service Mapping to be brought to the “virtual” reality, there were a couple of things needed like access to ServiceNow instance, MID Servers provisioned, IP Ranges defined or verified, server credential deployed, and so on. The implementation of Service Mapping was a long process which began with the entry points being configured and the top-level application being mapped. Then we had a couple of steps where the target host is discovered or already existed in the CMDB in which the service mapping process continued to determine whether there was a pattern match on the target application which was then added to CMDB with a connection relationship from the source host and application upon finding the match. In case of no match, the process stops itself. In this case, the service map was supported by an HAProxy, clustered Tomcat instances, and 2 Mongo databases.

For the challenges, we rediscovered the load balancers after getting proper access and permissions. De-duplications of duplicate CI and removed all duplicate entries and validated the service map. The Service Maps were validated by application owners and stakeholders. All the critical service maps were validated with SME’s to ensure the maps being configured properly and each dependency being captured accurately.


Service Mapping gave the customers visibility of all business services for each server in their supporting data. It gave the ability to determine the root cause of outages and related the top-down mapping of services in dynamically changing cloud environments.