Integrating ITSM and ITOM for a resilient IT experience

Jul 22 · 5 min read


Despite our best efforts to manage systems effectively, networks often contain problematic, obsolete, or outdated systems. System administrators often don’t realize their components and systems are obsolete until there is a crisis. The key to getting the most out of your systems and running your operations smoothly is to understand the status of your systems and make meaningful changes and upgrades. So how do you do it?

Let's say you're boarding a flight. The flight crew can be considered the service management team facing customers or end users. They guide you to your seat, provide you with safety instructions, blankets, and meals, and help you get to your destination smoothly. The operations team includes technicians, engineers, cleaners, air traffic controllers, and caterers who work behind the scenes to make it happen. There has to be a steady line of communication between service management teams and operations teams for your journey to be successful. Likewise, combining ITSM and ITOM can help you prioritize your operations effectively while delivering better service to your employees.

While ITSM is focused on delivering a service to end users or customers, ITOM is focused on the internal processes. By combining the two, you get the best of both worlds. This means organizations can:

  • Gain better visibility into IT processes
  • Reduce expenses and downtime
  • Decrease complexity and increase productivity
  • Identify gaps in compliance
  • Strengthen analytic and decision-making capabilities

That brings us to the question: how do we do it?


A configuration management database (CMDB) brings all your information to one place, allowing you to map the relationship between resources or configuration items (CIs) existing within your organization. Sysadmins often use an internal CMDB to keep track of the rapidly growing number of CIs. It covers everything from hardware and software, to people and services. A CMDB enables faster decision-making, especially in the cloud era where assets are created and moved around lightning fast.

CMDB relationship tree

How can you provide services to a customer without knowing what components are involved? The central CMDB must be accessible from both ITSM and ITOM tools.

Consider this: You experience downtime in one of the services you use. The monitoring solution takes note of it first and raises an alert for your IT team. This alert will be recorded as an incident in your ITSM tool, and must automatically be updated in the CMDB. This means all CIs related to this incident are updated in the CMDB. Both ITSM and ITOM must get involved for the CMDB to be updated.

IT asset management

The next natural step after establishing a CMDB is investing in an asset management solution. Admins need to monitor asset movement throughout its lifecycle, license compliance, and expiration; or as our teams call it: "knowing what's in our IT closet."

Let's go back to the previous example of a service outage. Once a service engineer is assigned a ticket, they identify the reason for the outage. Let's say the engineer found a single point of failure where a switch failed. This information is tracked in the CMDB as part of your assets. Your ITSM tool would include the details of the incident, the remedies taken to fix it, and measures taken to prevent its recurrence; while the CMDB would provide the engineer with the list of CIs connected to this switch, which could help in minimizing the impact of the incident.

Device end-of-life (EoL) management is also a recurrent use case that utilizes both ITSM and ITOM. Assume we have an old laptop without the latest OS version installed. If the system cannot be updated, the overall performance and security will likely be impacted.

A CMDB will have a list of all devices and their relationship with other devices. This device that is causing trouble cannot be allowed to hamper user experience, so ITOM must get involved as soon as it notices that an outdated device is still in rotation. That's where asset management will help us. The asset management module keeps track of the device's usage, its lifecycle, and a history of services it has undergone, then identifies its security impact through dependency mapping in the CMDB. If the device is just outdated and no longer supported, the asset management module will mark it for disposal.


When services take a hit, you don't have time to read through historical data, figure out what might have triggered the incident, and then fix it. That's where artificial intelligence comes into play. AIOps supports ITSM and ITOM tools by collecting vast amounts of data. Through machine learning, it analyzes past data and predicts incidents before they occur, enabling you to reduce your resolution time. AIOps tools have the power to read data from multiple sources, evaluate device health, conduct root cause analysis, and like a CMDB, enable quick decisions.

Coming back to our device EoL scenario, if a particular device or type of device is frequently proving to be problematic, we can use an AI-powered CMDB to gain deeper insights. Depending on the historical data produced by the device, including logs and error messages, we can predict with reasonable accuracy when a device may prove to be a problem. If we can predict the possibility of an issue, we can get the device changed beforehand, lifting a huge burden off of the ITSM tool and sysadmins.

About the author

Mahanya Vanidas, Content writer

Sign up for our newsletter to get more quality content

Get fresh content in your inbox

By clicking 'keep me in the loop', you agree to processing of personal data according to the Privacy Policy.