DCIM: what are the complementarities with ITSM practice? (Part 3)

By Laurent Duenas, August, 5th 2013 


Part 2 has introduced DCIM, its principal functions and benefits. It has also presented the major changes and challenges induced by the related technologies. In this chapter we will start to understand what are the intersections between both management approaches.  


What are the links between DCIM and ITSM?


What is the interest of DCIM for ITSM?

Physical components presents into the Data Centers, whether they are IT or not, come into the IT Services delivery chain as the others. Considering not only hardware failures, where the link with the IT Service availability is obvious, but all the ITSM management processes should be applied to this environment:


The management of capacities of power supply, cooling, rack hosting, network connectivity, and others, has to be aligned on the IT Service’s needs

► Architecture choices designed to provide redundancy must support IT Service’s availability objectives

► Automation principles for resource provisioning must respond with same agility objectives as IT Services require


Some examples of common concerns are presented below more to the point ITSM to DCIM alignment is vital for IT organizations:

iStock_000019244067XSmall - Data Center - DCIM 1.jpg

To cartography physical equipments

DCIM tools provide Configuration Management functionalities appropriate to the Data Center universe. They enable to list a whole inventory of the physical components. They also offer the possibility to represent through highly evaluated graphical displays, the links between physical components and their interdependencies as well.

For example: DCIM tools represent the relations between racks and UPS (Uninterruptible Power Supply) units; as with Physical Servers; connections between storage cabins and servers, etc. Though, these tools physically localize a component inside a rack or in an aisle with an “overhead”, “front” or “rear” view.

These tools fulfill perfectly all objectives the CMS* (Configuration Management System) looks for. They are seen by the latter as one of the possible data sources. DCIM’s repositories are considered as “physical CMDBs**” by the CMS.

* CMS is vocabulary from the ITIL V3 framework. It is more commonly known as CMDB (Configuration Management Data Base).

** “Physical CMDB” is vocabulary from the ITIL V3 framework identifying all specific repositories of IT components and sourced from different management tools.

 Within DCIM tools, modelization, recorded data, and the naming convention employed are often ruled by proprietary, embedded guidance. Within logic of integration to a CMS, the principles of data description must comply with a global data-model which encompasses all components and their requirements ensuring a uniform use of the information.

For example: Relations between components are mandatory to understand the impact of a change or to diagnose the cause of a service outage. In order to avoid any useless replication, it is preferable those relations be described at the right component level. To make those links exploitable, a unique data model must impose a common normalization in order to provide consistent definition to the relations. 

Without integration of DCIM’s repository contents into a global data model, the analysis activities cannot be conducted based on an end-to-end vision of IT Services.

Today, company initiatives remain guided by technical silos perspectives, hardly ever unified between stakeholders. The following inconsistencies are often encountered: 

► CIs comprehensiveness

► Granularity level

► Naming convention uniformity

► Relationship consistency

“Configuration gathering” coherence


 In the actual state, DCIM repositories are only used by their owners, which is not unusual. Many other repositories experience the same situation: as Data bases, virtual/logical servers, applications, workplaces, identity and security repositories, etc.


Industrialize the monitoring of the Data Center

As a focal of their offering, DCIM tools provide physical infrastructure monitoring features. They can detect hardware failures, abnormal activity flows, warn about overflows, and send alerts when an event is potentially endangering IT Service availability. Provided services are mostly identical to monitoring tooling employed to pilot an IT production. These are assimilated to ITSM automation tooling.


For example: all facility equipments such as dampeners, air cooling, UPS, ventilation-fan, PDUs (Power Distribution Units), pumps, fire protections, are all monitored by these tools regarding their individual capacities. 


Today, in the very specialized domain of Data-Center operation, principles for alert handling are defined from a specialist perspective - far from the Service-oriented one suggested by ITSM. DCIM monitoring should be considered as a complementary capability in order to contribute to ITSM objectives of the Event Management process.


For example: Event detection principles, alert triggering, alert display features, and all management rules (such as acknowledgement, assignment, escalation, removal/suppression), are related to the vocation of the alert and its criticality level. As a result, a message alerting for a power supply failure of a 19”- Rack will be managed through Incident Management, due to its potential severity. Another message informing about File-server occupation will be managed under Incident Management only if a Service breach could happened in a close timeframe. If this message is just trend information, it will be taken by the Capacity Management process. 

A lack of process harmonization leads to discrepancies between management methods. For a same event nature, 2 different support groups will result in providing different response time. These gaps experienced by end-users can not be accepted from a Service Management perspective. Both groups contribute to the same IT Service (see article about “IT Services a badly shared notion" ).


Copyright © 2013 - PRACT Publishing