If you’ve been following Nlyte at all over the past year, you would have observed several announcements regarding Connectors to our DCIM suite. You might ask, “What’s all the fuss?” or, “What’s wrong with your suite that you need all these Connectors?” or “Yet another connector?” or, “aren’t all connectors the same?” So allow us to explain. The answer to the last question is a resounding, “no, not all connectors are the same.” Part of the appeal of Nlyte’s march on connectordom is that they are flexible and don’t require re-testing and re-programming every time software is updated – all that’s required is perhaps some reconfiguration settings and that’s it. To answer the other questions, let’s examine the roots or beginnings of Data Center Infrastructure Management itself. According to Wikipedia, DCIM deployments over time will integrate information technology (IT) and facility management disciplines and data center infrastructure management (DCIM) is a category of solutions which were created to extend the traditional data center management function to include all of the physical assets and resources found in the Facilities and IT domains. This goes back to the rationale behind Nlyte’s recent wave of connector rollouts. The fuss is about including or connecting to the IT domain. But not just any part of IT, the ones that have to do the most with a Data Center’s Physical Infrastructure, and from the industry’s leading products.
Let’s start with configuration management databases (CMDBs). They host information on configuration items (CIs) or assets. Again, citing our good friend Wikipedia:
Its contents are intended to hold a collection of IT assets that are commonly referred to as Configuration Items (CIs), as well as descriptive relationships between such assets. When populated, the repository becomes a means of understanding how critical assets such as information systems are composed, what their upstream sources or dependencies are, and what their downstream targets are.
Any DCIM system not connected to an organization’s CMDBs is asking that organization to silo its information. Instead, a connected CMDB-DCIM system allows each to enrich each other.
Another key piece of ITSM software is Change Management systems. Reviewing its Wikipedia entry shines some light on the subject:
The objective of change management…is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to control IT infrastructure, in order to minimize the number and impact of any related incidents upon service.
Sounds scarily similar to a large part of what DCIM is supposed to do, right? Manage moves, adds and changes within the data center? Again, by not connecting/synching/coordinating with change management systems you run the obvious risk of siloing your IT team from your Data Center team, and becoming uncoordinated, with the potential for great loss (too great to cover here).
And I didn’t even consider virtualization hypervisors, lest you not know where your VMs are running, on which machines, should there be a power, space or cooling issue.
So stay tuned, the team at Nlyte is dedicated to building the bridge between DCIM and ITSM!
Nlyte offers Connectors for these products:
CMDB/Discovery – for bi-directional configuration item (CI) / asset information sharing and reconciliation:
Change Management – for workflow process management and communication:
Virtualization Hypervisors – for simplifying the management of physical and virtualized resources:
Sensors – tightly integrate asset location and/or environmental performance information:
- RF Code
- APC Netbotz
Power and Rack Planning: