Configuration Management Database (CMDB)

Revision as of 22:56, 7 December 2022 by User (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Definition of Configuration Management Database (CMDB)

Configuration Management Database (CMDB) is a centralized repository that stores information on all the significant entities in your IT environment. The entities, termed as Configuration Items (CIs) can be hardware, the installed software applications, documents, business services and also the people that are part of your IT system. Unlike the asset database that comprises of a bunch of assets, the CMDB is designed to support a vast IT structure where the interrelations between the CIs are maintained and supported successfully.[1]

A CMDB contains the configuration items (CI) or information system components within an enterprise IT infrastructure. It helps identify the different components of an information system and their configuration and stores this data in the form of metadata. The CI stored by a CMDB can be any IT component from hardware, software, network and/or IS policies and documentations. Typically, a CMDB automatically detects all components/CIs within an IT infrastructure/environment and keeps track of changes as they occur. CMDB provides data about these components in an organized way, making it easier for an organization to review and evaluate the data.[2]

Configuration Management Database (CMDB)
source: Adaptive Dynamics

Configuration Management Database (CMDB) is an integral part of IT Service Management (ITSM). It is a repository that stores information about configuration items (CIs) throughout the service lifecycle. It also describes the attributes & relationships between those CIs. As described in ITIL, CMDB is the fundamental component of the ITIL Configuration Management process. Also, it also helps to understand the relationships between the components of a system and track their configurations. The Configuration Management Database (CMDB in ITIL) also coordinates with Incident Management process for receiving updates on replaced components that need to be updated in the database. The minimum number of attributes and data that the CMDB should stores are as follows:

  • CI Unique Identifier or Identification Code
  • CI Name or Label (often, both, long names and short names)
  • CI Abbreviations or Acronyms
  • CI Description
  • CI Ownership (organizations and people)
  • CI Importance[3]

Characteristics of CMDB[4]

CMDB is only as good as the data it contains. The data must be accurate, regularly updated, and available to associated processes in order for it to be useful. Other characteristics of a useful CMDB include the ability to:

  • Simplify the coordination and reconciliation of input from multiple data sources.
  • Unify data through automation or federation, identify CI duplication, and correct exceptions.
  • Minimize costs and errors through reduction of manual input.
  • Provide clear views of CI relationships for Change, Incident, and Problem Management.
  • Support Asset Lifecycle Management.
  • Provide the flexibility to scale in order to support additional CIs.
  • Establish and maintain relationships and application dependency mapping.
  • Support dynamically changing environments.
  • Improve efficiency and stability through better visibility of CIs.
  • Reduce risk and improve security because every CI is recorded and monitored.
  • Improve compliance with business rules, monitoring, and auditing, including warrantee and license tracking.
  • Develop accurate budgets for future purchases.
  • Provide easy access to data.

Implementing CMDB[5]

  • Build a Logical Data Model of the Service Asset & Configuration Management Process with Relationships: The first step in the process is to create a logical model of the Service Asset and Configuration Management (SACM) process. The logical model defines the scope of SACM activities. In other words, the logical model explains how deeply the organization would like to trace SACM relationships. For example, at a basic level, it is possible to draw relationships between key services and the underlying infrastructure (hardware, servers, software, and interfaces). At the other extreme, SACM could trace relationships down to the workstation level.

CMDB Model
source: Beyond20

If you have a logical model like the one in the example above, you know Server 2 is connected to redundant Switches A and B, which are in turn uplinked to Router XYZ, and that Server 2 is critical to the business as it relates to Service B20, then you have the type of risk analysis data that will help determine the likelihood that you can reboot Router XYZ at 2:00PM on a Thursday afternoon without causing an unplanned, major outage. This is why maintaining the CMDB is so critical. Without vigilant updates, it becomes an obsolete data repository that no one trusts, and it undermines your organization’s Change Management process.

  • Define Configuration Item (CI) Types: Next, you’ll define CI types based on the logical model developed in Step One. Essentially, this entails categorizing any and all configuration items you’re interested in managing (server, switch, router, database, etc.). Warning: A lot of people go astray here by trying to do everything at once. Trying to map all the relationships and keep track of every asset you have is going to be extremely difficult, so start small. What are the most important things you need to keep track of? Where are your weak points? What is currently in scope for Change Management?

CI Types
source: Beyond20

  • Assign an Owner to Each CI Type: Next, you’ll identify and assign an owner for each CI type identified in Step Two. The CI Owner will be responsible for the remaining steps for their respective CIs. For example, if Jane is the owner of all your servers, she will be responsible for deciding what information we need to know about each server, and how to gather that information.

CI Type - Owner Assigned
source: Beyond20

  • Define Attributes for Each CI Type: Now that you have owners defined for each of your CI Types, they will define attributes for their respective types. An Attribute, per the ITIL publications, is a piece of information about a CI such as name, location, version number, or cost. In our example above, Jane will define all the attributes we need know about our servers and record them in the CMDB.

CI Type - Attributes Defined
source: Beyond20

  • Identify Sources of Information for Your CIs (ie. Discovery): Once CIs, attributes, and owners have been defined, it’s important to understand where that information can be found. For example, an auto discovery tool could be used to identify related components on the network. Other options include visually inspecting hardware components to obtain serial numbers, reviewing purchase and warranty documentation, and even reviewing invoices.

CI Type - Information Sources Indentified
source: Beyond20

  • Map Relationships Between Assets: This step provides context to the information collected in previous steps. Here, we’re mapping relationships between components. This is akin to taking the logical data model created in Step One and overlaying it with the actual hardware, software and infrastructure components that exist in your environment. When feasible, an auto discovery tool can dramatically reduce the amount of time it takes to perform this mapping. If using auto discovery is not possible, relationships can be drawn manually. Word to the wise: Even though this can be done manually, keeping it up will be much more difficult! Just like with humans, relationships between CIs can be difficult to maintain! A tool will make the whole thing much more pleasant.

CI Type - Relationships between Assets
source: Beyond20

  • Rollout One CI Type at a Time – Don’t Try to do it All at Once!: In this step, CI types and associated attributes are actually built or loaded in the CMDB. An incremental approach works best here. Build out one CI type first and verify that it is correct before moving on to the next. For example, if you start with Servers, identify all of the servers, then identify all the attributes and owners associated with each one. Your last step – an extremely important one – before moving on to the next CI type is to verify that the relationship mapping between servers and other components is correct. When that’s confirmed, onward.

CI Type - Roll Out
source: Beyond20

Creating a valuable, current CMDB is not something that will happen overnight. The steps outlined here take time to implement; how much time depends on the resources you have available in your organization. This takes effort. And it takes a lot of buy-in up and down the org chart. The good news is you probably already have a solid start, or maybe even a complete CMDB waiting to be maintained. Ultimately, active administration is the key to success when it comes to configuration management.

CMDB Administration Processes[6]

A CMDB like any other database application depends on effective management of certain ongoing processes. These processes do not manage CI content that have already been assigned to Domain Owners. They are different from business database applications, so special attention is required to ensure they are assigned and implemented. The identification and description of these processes is listed in the table below, but refining and formalizing these will need to be included in the particular implementation. A CMDB Administrator will need to be assigned the responsibility for these processes, except for the DBA task, which should be handled as part of the normal database environment. After the initial installation it should take no more than two days a week. Good candidates for this role are Change Manager or a person who works with the technical architect or application lead or software configuration manager, but only if they are familiar with technical infrastructure. Operations personnel are not good candidates as they are unfamiliar with higher-level applications and business service CIs and relationships.

CMDB Administration Processes
source: Evergreen

  • Physical Maintenance: The DBA will need to assist with monitoring the physical CMDB instance and table spaces. Although there may be millions of CIs the database should not significantly grow over time unless there is:
    • Heavy use of snapshots, in which case it will grow quite rapidly
    • Extend CIs with documents or CLOBs (which is not recommended)

Accepted practices for business applications such as running fine-grained daily backups, redundancy, maintaining test platforms and data, etc., are not critical for a CMDB unless a data center move or disaster recovery plan is in the offing. The reason is that if the database is lost, the discovery engine will rebuild almost all of the data. The key is to understand that it is just a tool and not mission-critical. If resources are limited, then save the storage space for snapshots.

  • CI Type Change Control
    • As opposed to CI itself
    • Secondary – need should come from Domain Owner
    • Add/change CI Types and attributes
    • CI fix (missing, duplicate attributes)
    • Change primary key identifier
    • Correction of CI assignment – can’t be high level
    • How would configuration information help?
  • Discovery Monitoring: The discovery engine(s) are scheduled processes. A monitor/alert needs to be configured to indicate failures or the discovery logs need to be inspected daily. Pay particular attention to monitoring memory and heap usage. Some discovery engines allow the scheduling of runs by protocol or CI Type. Tradeoffs must be made to balance timeliness with execution time and change volatility. An example of this is the IP address changes which happen infrequently, making rediscovery a lower priority. If your discovery engine utilizes credentials, then a process needs to be established with Security Administration and possibly the network, application and server administration groups if access permissions are managed at different points. This is different from CMDB user administration. Discovery credentials are usually in readonly administrator or system monitoring domain accounts. Credentials like a SNMP community string do not frequently change; however, a coordination point is still needed.
  • User Access: Users need to be granted role-based access to use functions within the CMDB. CI Domain Owners will have more permissions than those only viewing shared maps. Some network information is sensitive data that could provide damaging insight into the technical environment. Typically the user base for a CMDB is less than 75 and does not frequently change, so it should not require more than one hour a week.
  • Enterprise Views: Graphical maps, reports and other standard queries can be a bit different for a CMDB. The CMDB Administrator needs to be a go-to resource for configuring complex or enterprise views. Domain Owners need to be able to modify and maintain their own views.
  • Global Changes: The IT organization may occasionally implement large-scale changes in the infrastructure that affect many identifiers, IP DNS or how management services like JMX or SNMP are configured. The CMDB Administrator should manage the rediscovery process and report the changes so redundant events and deltas are understood.
  • Enhancement to Satisfy View Requirements: After CI Domain Owners begin using the initial set of views they will have new ongoing data requirements like any reporting system. Some views will require new CIs. The CMDB Administrator will need to activate and test new discovery packages or configure custom discoveries to meet future analysis needs.

Configuration vs. Asset Management

One very common challenge, as mentioned earlier, is taking a purely “Asset Management” approach to Configuration Management. This often occurs duplicate data frequently appears in both the CMDB and Asset Management database. While it’s true that both systems may include the same asset or configuration items, the purpose of the systems are very different.

  • Asset management monitors and manages something of tangible or intangible business value through its lifecycle from purchasing, to operating, to eventual disposal. Tangible assets can include laptops, routers, printers, and software applications that are also part of the CMDB, and/or desks and chairs and other items that are not part of a CMDB.
  • Configuration Management can be considered a larger initiative than Asset Management. Configuration Management maintains information associated with CIs, such as associated configuration attributes and relationships, that are necessary to effectively deliver an IT service. Configuration Management also performs the functions of managing CI interrelationships, CI status, and the impact of a change on associated CIs. Several other ITIL processes rely on the CMDB data to function.

CMDB for IT Asset Management[7]

CMDB holds information about your assets, items related to them and any connections or relationships between them. IT and network devices, as well as software and virtual machines, can be represented in a CMDB. So can people, products and services (not just of the IT kind), facilities, clients and suppliers. With today’s complex IT environments, a software-driven CMDB makes sense for IT asset management, although the initial interest of some years ago did not develop as much as predicted. Now, a new trend in IT could change that. A smart CMDB application/database can give you a number of useful pieces of information and insights into your IT asset management. For instance, you can see not only what you have, but also how it has been installed and configured, how each asset interacts with others, and whether configurations have been changed from the officially sanctioned versions.

CMDB for IT Asset Management
source: OpsCentre

Slicing and dicing these data can then also help not only with IT support and troubleshooting, but also with business intelligence insights into the interactions between IT and the rest of the organisation. These advantages however come at a price. The CMDB system must be acquired, and constantly updated and maintained to ensure that the data mirror exactly the real state of the assets. The change in IT that could give an extra boost to the use of configuration management databases for IT asset management and more is DevOps. Highly automated, DevOps relies on different software modules for integration, testing and deployment of new applications and also relies on the correctness of the application components from one end of the DevOps life cycle to the other. In the same way that a CMDB can be used for auto discovery of IT assets in general, it can also serve to automatically discover new DevOps code at different stages and to check that the version of such code corresponds exactly to official design and deployment specifications. The net effect on CMDB solution usage remains to be seen.

CMDB Challenges[8]

While not particularly highly visible, a well-managed Configuration Management Database (CMDB) provides organizations with tremendous value. In addition to this value, a CMDB requires an organization to take responsibility for keeping it fit-for-purpose. Hewlett Packard Enterprise (HPE) sponsored a leading analyst firm to poll 100 IT executives on CMDB and discovery tools. The most interesting findings on CMDB challenges are listed below:

  • Reconciling data between multiple discovery tools or databases: A CMDB is a great place to consolidate information, as multiple business functions, including IT services, operations and asset management use a CMDB. Since most CMDBs are only populated using discovery tools, this data must be verified and augmented using multiple data sources to make it useful to all relevant functions.
  • Achieving accurate discovery in dynamic environments (clouds, containers): Virtual, cloud and containerized systems can exist for short periods of high demand, during which their existence must be extracted from log files. These virtual systems must have their configurations verified for billing, software license use and security vulnerabilities, similar to physical servers.
  • Maintaining human expertise required for CMDB maintenance and updates. CMDB maintenance is a skilled task. Duplicate and missing assets must be accounted for, and attribute values associated with each asset record or Configuration Item (CI) must be populated with the most reliable values. Multiple potential values must have any conflicts or inconsistencies resolved. Large CMDBs containing thousands of values require skilled people who can reliably evaluate conflicts when specifying precedence rules.
  • Compliance-related concerns with maintaining CI data: Vendors often surprise businesses with license compliance audits, which can be allayed with an accurate CMDB. If you don’t have your own reliable license count, then you will have to apply resources internally to verify this. Alternatively, you will have to use the vendor’s figures, which may mean you are paying a premium. At a more serious level, the CIO is required to maintain an accurate count of IT assets to avoid the possible impact of Sarbanes-Oxley section 404, which mandates adequate financial reporting.
  • Costs (human/system) of maintaining accurate CI data: The high cost of maintaining the accuracy of the data in a CMDB increases exponentially against increases in asset volume. Automating this task requires the maintenance of complex precedence rules at a CI attribute level. True accuracy requires a minimum of 2 or more data sources in addition to the source CMDB records. The cost of manual reconciliation is prohibitive once asset numbers increase to thousands, and is prone to human error.

Benefits of CMDB[9]

The subsequent points define the possible advantages you can expect from a CMDB.

  • Asset Management: The CMDB delivers a constantly organized relational data warehouse for CIs that are regarded as IT assets. Persons accountable for IT asset management can refer CMDB to know about the association of assets with the organizational entities, workforces, cost centers, best practices in use, and so forth. This not only lets you know what CIs are regarded as assets, but also who is using what assets, where the assets are positioned, who is disbursing for the assets, and what IT processes are linked to those assets. The CMDB allows you to spontaneously resolve and analyze data about your implemented assets and their alignment with professional business services.
    • Possible hard benefits: Lesser asset TCO and procurement expenses, removal of unnecessary redundant asset acquisitions, extra proficient resource sharing, more precise financial arrangements and forecasting
    • Possible soft benefits: More positive control and superior analysis of your IT assets during the course of their working lifecycles
  • Project Management: The CMDB, alongside the change and release management process, is responsible for the process to classify, strategize, analyze, modify, and manage the projects that generate new CIs, update CIs, or implement cases of CIs. Having change and configuration management combined into the project management lifecycle is critical for guaranteeing an uninterrupted project-to- production changeover and precise CI status.
    • Possible hard benefits: Better realization rate and decreased expenses during projects
    • Possible soft benefits: More team and client gratification because of smoother deployment of projects
  • Service Performance and Quality Management: The CMDB offers the facility to associate incidents and problems to services and resource groups, so you can assess the services, support, and organizational statistical data. A clearly written CMDB is a reference of the info to support processes, value reporting, service design, and records.
    • Possible hard benefits: Improved assessment of performance to increase effectiveness and decrease expenses
    • Possible soft benefits: Increased user approval rates through quality service of highest quality
  • Contract Management: The CMDB delivers essential statistics about how to efficiently accomplish an agreement with a service client. Such info comprises of real performance traced against agreed upon goals, bills and expense particulars, contract time period, and extension information. This information is willingly accessible for incident-by-incident contract management as well as overall performance.
    • Possible hard benefits: Decreased expenses through more active management
    • Possible soft benefits: Clear & transparent client relationships
  • Audit, Governance, Compliance, and Control: The CMDB delivers an important source of control-related statistics valuable for both internal and external audits. The Control Objectives for Information and related Technology (COBIT) framework, for instance, endorses IT controls that can efficiently influence information from a CMDB. COBIT is an industry - standard control structure that delivers a set of high - level control objectives for IT practices and is used to evaluate the control system of an IT organization.
    • Possible hard benefits: Better capability to deploy IT controls required to meet various guidelines that influence IT operations
    • Possible soft benefits: Greater confidence in audit and compliance skills

See Also


  1. Definition - What is Configuration Management Database (CMDB)? Manage Engine
  2. Explaining Configuration Management Database (CMDB) Techopedia
  3. Understanding CMDB Cert Guidance
  4. Characteristics of CMDB Cherwell
  5. Implementing a CMDB in 7 steps Beyond20
  6. CMDB Administration Processes Evergreen
  7. CMDB for IT Asset Management OpsCentre
  8. The Top Five CMDB Challenges Blazent
  9. Benefits of Configuration Management Database (CMDB) Grey Campus

Further Reading