Importance of business service map in IT

Why is a business service map critical for IT management?

Business service mapping is the area of configuration management that perplexes so many IT professionals. Yet, it 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
  •  The CMDB isn’t current or updated

It’s worth understanding the reason service mapping is so critical and how it adds 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 you can visually display. This enables people to see the relationship between the service and its component Configuration Items (CI) and 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 you understand the cause behind the reported service issues, as well as see other impacted services.

Commonly, if you log an incident or event against a configuration item, the service management platform will identify this within the map. There are three 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, 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 a questionable end result. The data contained in the maps is better than nothing initially, but as time passes 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 business 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 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 more efficient. You only need non-discoverable data to manage the CI. You need to manually perform the final logical link of the application layer to the business service. Or you can build them 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 business enterprise 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 is critical for audits and root cause analysis.
  • A mechanism for identifying the non-discoverable data and managing it is critical. 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.

Use cases

Almost any individual trained in IT Service Management (ITSM) can tout the use of a CMDB. The CMDB leverages business service mapping when it comes to event and incident management. However, there are other use cases worth mentioning:

Risk Management

You can leverage the IT service map for risk management. You can review services for such risks and consider the cost-benefit of providing redundancy against the criticality of the service.

Change management

If you propose a change against a particular CI, you can view the map to see the affected services and their business criticality. You can also identify whom to inform and whether the CI is redundant or a single point of failure.

(See, Transforming Change Management with Virima’s CMDB and ViVID™ Maps)

Incident Management

Incident Management leverages the CMDB and its service maps during root cause analysis.

  • Any changes made against any of the CIs that support the service.
  • Any supporting CI that has incidents logged against it.
  • Changes to the service’s baseline map. For instance, take a post-discovery baselined service. You could view the changes to its architecture by comparing the current service map to the original service map.

Security operations

These rely on business service mapping to prioritize and address security vulnerabilities. You can first identify the CIs in the enterprise that match the vulnerability report. Then, you could view the criticality of the service(s) that the CI supports. Business service mapping plays a key critical role in protecting the organization from attack. It enables effectiveness in vulnerability management and response,

Service availability reporting

Service mapping enables the reporting of service availability by providing the correlation. You need this 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. You can determine the TCO of a service by identifying maintenance costs for all components. You can then apportion them across appropriate services .

Machine learning and predictive analytics with enterprise data

They make it easier to analyze a large amount of data. This helps to work more proactively than ever before. Proactive maintenance of infrastructure and applications and in terms of providing “tips” to service desk agents taking calls. You can significantly save costs here by shortening or preventing downtime. However, these approaches need a CMDB that has IT service mapping capabilities in place to be effective.

Several of the use cases here 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. They can do so by picking the right service mapping tool for their needs. 

Virima simplifies service mapping and IT discovery

You can integrate ViVID (Virima Visual Impact Display) Service Mapping and Virima Discovery with other third-party applications including Ivanti, Cherwell, ServiceNow, and Jira.

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.

Contact us today to schedule a demo and explore the possibilities!

Similar Posts