Author Jigs Jamnadas
Why do we need a CMDB?
Why do we need a CMDB?
A CMDB is a repository of your IT equipment configuration records to assist tracking their lifecycle. According to ITIL (4), this repository can contain records of hardware, software, systems, documentation that all impact or may be impacted by changes and events in your organisation’s infrastructure. The purpose of the CMDB is to have a single “source of truth” that can be relied upon and trusted.
It supports your IT Service Management processes to associate Incidents, Problems and Changes with Configuration Items (CI) in the CMDB. Relationships between CIs allows the impact of change or events to be determined and allow staff to make informed decisions.
Having no CMDB forces an organisation to question the reliability of information provided during critical times, such as a major incident, and potentially make decisions based on inaccurate or stale data. This may result in increased resolution times and outage durations.
When the CMDB is populated with related information, combining it with Event Management allows for CI status information to be added. Event management can be used to track availability of the CIs in near real-time and proactively indicate issues as they occur. This will reduce the MTTR through notification and visualisation, along with access to the dependencies to show impacted services.
What do I put in my CMDB?
Before determining what needs to be in your CMDB, you need to agree on the level of detail to be captured.
Not all businesses are equal and how they are structured to manage their IT environment varies from organisation to organisation.
Some businesses need to have detail down to the component level, while others just want to track the services that they deliver. Outsourcing of IT could affect the amount of detail available to be populated into the CMDB and affect the level and granularity of the content. Having a workshop around these points will avoid potential over-population or under-population of the CMDB information and possible re-work if it is wrong.
The main aim is to have enough information for the business to operate with sufficient information to avoid gaps and provide trust in the information contained in the CMDB. Most CMDB deployments fail because the data contained is unreliable and inaccurate and provides no benefit in times of need, such as during changes and outages.
Simply having the CI information alone does not provide any benefit other than a list of items.
A true understanding of the infrastructure for IT is obtained by adding relationships between the CIs so that upstream and/or downstream impacts can be determined when a CI is changed or broken.
As an example, an Email service depends on multiple components or devices, software and configuration to work effectively. From the internet side, there is the internet connectivity; the gateways (modems, load balancers and routers), firewalls, switches, hosts, software, storage devices, etc. All of these elements contribute to the ability to send and receive emails.
If any of these components stops or is re-configured, the entire email service could be compromised. By using the CMDB to hold the information and the relationships between them, resolution of an outage to these components can be more rapidly traced and rectified.
Not all businesses are equal and how they are structured to manage their IT environment varies from organisation to organisation.
How do I populate my CMDB?
Once the content for your CMDB has been agreed, there are multiple ways to populate the CMDB with data. Lists and Spreadsheets is a simple method for a new CMDB but assumes that the contents are accurate. As soon as the data is stored, processes need to be in place to maintain the accuracy.
Having the CMDB aligned with the Change Management process allows for alterations to the CMDB content to be traced and validated. The challenge with this method is that the relationships between the content needs to be manually provided and maintained.
How does ServiceNow assist with populating my CMDB?
ServiceNow provides its own Discovery tools to assist in populating the CMDB as well as establishing the relationships between the discovered items. Other configuration management offerings are available that are integrated with ServiceNow, such as Microsoft’s SCCM or Altiris. ServiceNow can also use JDBC connectors to pull data from Database sources such as data warehouses or external CMDB repositories or use Web Services to access other CMDBs.
Notes
Most “Discovery” tools often do not determine how much information will be stored in the CMDB. Typically, they discover “everything”. As a result, decisions around the scope and granularity for the CMDB can often be overridden by the “tool” used to populate it. When this occurs, being able to limit what is visible to the consumers of the CMDB information needs to be considered.
What about your “cloud” assets and infrastructure? ServiceNow can retrieve this information from “Cloud” sources like Azure, AWS and VMWare directly, rather than using the on-premise discovery methods.
How do I maintain my CMDB?
CMDB maintenance is important to provide accuracy and trust in the CMDB content.
Basically, an unmaintained CMDB is stale from the date of installation/population; as most IT organisations are not static and there are infrastructure changes taking place on a regular basis.
Change management is a fundamental component in maintaining a healthy and accurate CMDB. If components need to be replaced, upgraded or migrated, an audit trail of these alteration needs to be kept. “Incidents caused by change” is a significant affecter on IT, so having the audit trail allows IT to quickly identify the root cause. Even changes to hardware, such as memory, storage or other resources could impact services being delivered through these components.
When a change is raised, steps need to be added to ensure that the CMDB has been updated to reflect the alterations and maintain the accuracy and “close the loop”. This may include decommissioning of items as well. The relationships need to be updated to maintain the dependencies between CIs.
While “discovery” tools will update the CMDB on a regular basis, many “discovery” tools do not cater for equipment that has been decommissioned as they only record the current state of the environment based on what they can see at the time of scanning. This can lead to the CMDB having extraneous and potentially erroneous information that could misrepresent the accuracy of the supporting systems relationships.
How do you deal with dynamic environments like virtualised and on-demand? These CIs may change configuration based on load and resource requirements. Changes will be under the control of the virtual or on-demand provider configuration and may cause unauthorised or unexpected changes to the layout and structure relationships.
Will these occurrences cause false events or extraneous noise when they occur? How current is the model and when was it last updated? Has this been catered for in your CMDB design?
How do I start my CMDB Journey?
The journey always starts with identifying what you need from your CMDB.
Decisions about the content and granularity need to be determined at the beginning to avoid re-work. Establishing how much information needs to be entered and maintained depends on the organisation.
Workshops
Workshops with CMDB experts will allow this information to be captured and agreed before any Configuration Items are added to the CMDB. Identifying the scope allows the organisation to right-size they environment to meet their Service Delivery requirements.
As mentioned previously, “discovery” tools may override the scope with excesses of information. While there is the convenience of this method for populating the CMDB, consideration for the consumption of the CMDB data will need to be established as part of these workshops.
Classes
Once the scope has been established, ensuring all the CMDB types (classes) exist in the proper and appropriate structure needs to be added. Some of these classes may be extensions available from ServiceNow; Telecommunication classes for example. Any classes that are not found in an existing extension may need to be manually added.
Sources
Identifying the source of CMDB information to be populated is next. This may be manual, either by import or keying, or it may be from a “discovery” source or feed from a cloud provider.
ServiceNow allows for multiple sources of CMDB data to update the same CI records where relevant information contributes to the accuracy of the CI record. This could start as a manual source and is enriched by a “discovery” source. The frequency of the information updates needs to be established against the impact and/or workload to maintain the data.
The currency of the information could impact the ability to identify root cause for outages, so the collection intervals need to be considered.
Relationships
Ensuring that the relationships between the CI records needs to be added and maintained.
Discovery normally provides for this at a CI record level in what is termed as a “Horizontal Discovery Model” which is a layered approach. Business Services, such as in our “Email Service” example, may share infrastructure with other business services. Establishing these business service relationships is much more complex.
ServiceNow has the “Service Mapping” feature that assists in deriving these relationships using a combination of automation through discovery and manual manipulation for more bespoke services. Service Mapping uses a “Top-down Model” whereby the user entry point is at the top of the hierarchy and the dependencies are mapped vertically so that all impacted components are included in the visualisation.
Other integrations
Integration provides a method for data enrichment. These are used to ensure a single source of truth. Disparate sources can contain current information pertaining to the CI record. By allowing these sources to enrich the CI record, it ensures that the latest data is available for decision making when it comes to changes or impacted systems through an outage event.
Guidance
Start small and evolve. The big-bang approach is more difficult to scale and confirm. Discovery sources pull a lot of information into the CMDB and this can cause trust and reliability concerns.
Limit the initial discovery to a small, known subset of your environment and validate, validate, validate. This will establish confidence in the scope of what is needed. Expand the scope incrementally so that confidence is maintained.
Contact us
Contact us as partners in your CMDB journey. Red Moki provide Advisory and Implementation Services. Our functional consultants have many years of experience in the design and implementation of end to end processes for IT operations. Not just that, they also have practical experience of having been operational mangers in large complex environments.
