The area of configuration management that perplexes so many IT professionals, yet that which provides the highest value in Configuration Management Database (CMDB) projects, is the service map. There are several major reasons IT gets stopped when it comes to service mapping:
- IT finds it difficult to define business services.
- Service mapping software often maps to the technical application service (for example, HTTPS services) rather than the business service level.
- Without service mapping software, the process is extremely time-consuming.
- Is the CMDB current and up to date?
It’s worth understanding the reason Service Mapping is so critical and how it provides value. This makes it possible to make a business case for using service mapping software and tackling the service mapping exercise.
Understanding Service Mapping
In the context of the CMDB, service mapping is the process of defining hierarchical relationships that can be displayed visually, enabling people to see the relationship between the service and its component configuration items, as well as the relationship of the items to one another. The beauty of the service map is that when integrated to other applications within a service management platform, it can show potential impacts to a service or help understand why service issues are being reported.
Commonly, if an incident or event was logged against the circled configuration item, the service management platform will identify this within the map. There are two ways this will be useful:
- If a monitoring solution identifies an issue with
this configuration item, an operator (or predictive intelligence engine) could
identify it as a single point of failure, potentially impacting the service at
the top of the map (or multiple services if used by more than one)
- Information in the service record could identify the business criticality of the service, the business groups that use it, or support it and its expected operational state and service hours. This provides the information needed to triage the issue appropriately.
- If a service desk analyst were logging a call about this service and wanted to see if there were any known issues, opening the service map would identify a critical component with an event logged against it and the current status of that event. This eliminates the need to escalate an issue that’s already being managed or wasted minutes trying to figure out which piece of infrastructure is down before escalating the issue to the correct team.
The problem with service mapping is that mapping every component in an enterprise, particularly a large one, is an extremely intensive activity. Organizations sometimes attempt to tackle this as a manual activity with a two-pronged approach:
- Get technicians and developers together and manually identify every configuration item used for only the most critical business services then build the relationships manually.
- Use infrastructure design documents to build the service maps for new deployments, again manually replicating the design in the configuration management system.
This manual approach yields an end result that is questionable. The data contained in the maps is better than nothing initially, but as time moves on and errors are identified, people lose faith in the maps and the effort is dropped. The maps also need to be maintained in conjunction with the change management practice, which further decreases accuracy over time.
A Modern Approach to Service Mapping
This is no longer the case: automated discovery and service mapping tools are now available, automating several key activities:
- Identifying assets in the environment and their configuration information.
- Discovering and updating the technical attributes automatically, yielding a far more accurate picture of the item’s configuration (now elevating the asset to a configuration item).
- With service mapping tools, seeing traffic patterns and other information that enables the service mapping tool to map the relationship between configuration items (CI), often to the technical service or application level.
With these time consuming and often inaccurate tasks done accurately through automation, the act of building and managing the CMDB becomes much simpler and can be done far more quickly. Only non-discoverable data is needed to manage the CI and the final logical link of the application layer to the business service need to be performed manually (or built as rules in the mapping tool, where applicable).
It’s still important for organizations to have a repeatable and organized configuration management practice as planning is a big part of success when building a CMDB and mapping services:
- A discovery approach is needed for discovery to be run over specific networks during periods of lower activity to avoid potential performance issues.
- Once the entire enterprise has gone through initial discovery, automated maintenance runs must be defined to keep the discovered assets updated and discover new ones.
- Services need to be defined, at both the technical and business levels, including the applications that make up each service.
- A process for mapping the services, refining the rules used to map them, and re-running the service mapping effort until a service’s map is complete is needed.
- Processes for baselining the complete service configuration are critical for audits and root cause analysis.
- A mechanism for identifying the non-discoverable data and managing it is critical. It’s great that everything is known about the technical aspects of the CI. Still, someone has to enter the business criticality of the services, the support and approval groups as well as owners for all CIs and build the final relationship to the business service.
One key activity before kicking off an initiative is defining the roles and responsibilities of everyone involved and ensuring a plan is in place for the build phase and to maintain data over time. Taking into consideration that the CMDB becomes worthless, the minute technical teams have reason to believe data is inaccurate. They need to understand that they play a critical role in the effort and the quality of the data and what that role entails.
Business Use Cases for Service Mapping
Almost any individual trained in IT service management (ITSM) can tout the use of a CMDB that leverages service mapping when it comes to event and incident management, but there are other use cases worth mentioning:
- The service map can be used for the management of risk. In the map shown, there are several devices, including the one circled in red, that seem to be single points of failure. Thus, in an existing enterprise, services can be reviewed for such risks and the cost-benefit of providing redundancy considered against the criticality of the service.
- If a change is proposed against a particular CI, the map can be viewed to see the services affected and their business criticality, identify who needs to be informed (business owners/stakeholders, if tracked in the CI) and whether the CI is redundant or a single point of failure, which could increase the risk of the change.
- Problem management leverages the CMDB and its
service maps during root cause analysis:
- Changes made against any of the CIs that support the service.
- Higher than usual rate of failure of a component or incidents logged against it.
- Changes to the service’s baseline map: if a service is baselined after discovery, changes to its architecture may be able to be seen by comparing the current service map to the original service map.
- Security operations rely on service mapping to prioritize and address security vulnerabilities. This is done by first identifying the CIs in the enterprise that match the vulnerability report then by looking at the criticality of the service(s) supported by the CI. By enabling effectiveness in vulnerability management and response, service mapping plays a key critical role in protecting the organization from attack.
- Service mapping enables the reporting of service availability by providing the correlation needed to open outage records for all impacted services when a configuration item raises an alert.
- Service-based financial management or reporting relies heavily on service mapping as with service mapping maintenance costs for all components can be identified and apportioned across appropriate services to determine the true cost of ownership of a service.
- Machine learning and predictive analytics, along with data in many organizations service management platforms make it easier to analyze a large amount of data to work more proactively than ever before, both in terms of proactive maintenance of infrastructure and applications but also in terms of providing “tips” to service desk agents taking calls. There are significant cost savings here by shortening or preventing downtime, but these approaches need a CMDB that has service mapping in place to be effective.
Several of the use cases here make it possible to build a strong business case for the investment in discovery and service mapping tools. However, organizations still need to consider ways to optimize these costs by picking the right service mapping tool for their needs. To learn more about service mapping, sign up for our webinar 6 Steps to Service Mapping Success on 21st May, where you will learn about the real-life challenges and solutions to ensure a successful Service Mapping project.