Business service mapping – the area of configuration management that perplexes so many IT professionals, yet that which provides the highest value in configuration management database (CMDB) projects.
There are several major reasons IT gets stopped when it comes to service mapping:
- IT finds it difficult to define business services.
- The software often maps to the technical application service rather than the business service level. For example, HTTPS services.
- 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 exercise.
Understanding business service mapping
In the context of the CMDB, business 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 (CI), 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, as well as seeing other services that might be impacted.
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 challenge with mapping every component in an enterprise, particularly a large one, is that it is an extremely time intensive activity. Organizations sometimes attempt to tackle this manually with a two-pronged approach:
- Get technicians and developers together and manually identify every configuration item used for only the most critical business services and 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 dependency mapping
Automated discovery and service mapping tools can now be used to automate several key activities, such as:
- Identifying IT 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 efficient. Only non-discoverable data is needed to manage the CI and the final logical link of the application layer to the business service needs to be performed manually or built as rules in the mapping tool, wherever applicable.
Discovery planning process
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 imperative.
- Preparing 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
Almost any individual trained in IT service management (ITSM) can tout the use of a CMDB that leverages business service mapping when it comes to event and incident management, but there are other use cases worth mentioning:
- The IT service map can be used for the management of risk. In the map shown in the figure above, 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, 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:
- Any 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. For instance, 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 business 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, business 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 because 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 and 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 capabilities in place to be effective.
Virima features can automatically discover and map your critical IT resources and the interconnections that link them to one another, your applications and services, and your users.
Virima is here to help. To get started, contact us today to schedule a demo and explore the possibilities!