Implementing and managing CMDB is one of the most critical and complex tasks within ITSM program however a solid and mature CMDB can bring huge rewards for the IT and overall enterprise (Look at our other blog on why CMDB is important for your ITSM success).

By leveraging the right steps and best practices you can also implement and maintain a solid, complete and accurate CMDB for your enterprise. The following steps are based on leading practices and our experience that we gained by implementing and optimizing CMDB for several clients. These steps can be leveraged for a new CMDB implementation (e.g. if you are planning to implement a new CMDB due to new platform implementation) or for an existing CMDB optimization (e.g. if your current CMDB has data quality, governance, completeness, accuracy or performance issues). So, let’s start:

  1. Establish Core Team: Building core CMDB team with right members initially is critical for the entire CMDB initiative. In this step you should identify the core team members along with their responsibilities, below is a list based on our experience. In addition to the core team, there are other teams/members required for the CMDB initiative which the CMDB core team needs to bring in time to time.
    • Executive sponsor –  IT leadership member who will sponsor the initiative and is the escalation point for the entire CMDB effort
    • Configuration Management Team – This includes configuration process owner, configuration manager, analyst, CMDB platform developers etc.
    • Project Manager – Most of the time this is a forgotten role. Remember setting up CMDB is not a task but it’s a project. So, to manage the initiative appropriately its recommended to have a project manager. The project manager doesn’t need to be 100% dedicated to just this effort so the resource could be shared across multiple projects.

In addition to core team setup, establishing governance structure is equally important for the success of CMDB initiative. Apart from gaining leadership buy in, you should also keep leadership engaged throughout. Our recommendation is to set up an executive steering group which should be comprised of executive sponsor and other members from senior IT leadership. The core team should frequently meet with them to provide overall progress and any risks/issues/decisions for which their help is required. Setting up this cadence will go long way for the success of your CMDB initiative.

  1. Set Clear Objectives: Just like any other IT or Non-IT initiative you need to have clear objectives that you want to achieve, it applies to CMDB as well. To simplify objective setting we recommend leveraging use case driven approach as below:
    • Identify key stakeholders: First identify list of stakeholders that interact or leverage CMDB in your organization. Typically, these teams are ITSM Process owners (Incident, Problem, Change Management), Application Owners, Service Desk Lead, IT Infrastructure leads (Server, Storage, Database etc.), Compliance and Security Lead. You don’t need to engage every single person from these teams, but key representation is recommended.
    • Gather use cases: Collect use cases from the above stakeholders to understand their needs and type of information they would like in CMDB.
    • Define and prioritize CMDB goals: Leverage use cases to define CMDB goals and prioritize them. Prioritization could be based on organization’s IT initiatives priority, any critical issue resolution, leadership guidance etc. Below are few examples use cases and their mapping to CMDB goals:

Use Case CMDB Goal Priority
Business needs to understand the risk and impact of an IT infrastructure change(s) to the business Develop a configuration management database that contains Infrastructure elements and its relationship to the business services H
Application owner needs to know the impact of an Infrastructure component failure to the business applications Develop a configuration management database that contains Infrastructure elements and its relationship to the business applications M
Asset Management team needs to know the list of all deployed servers (physical and virtual) in the enterprise and supporting business applications Develop a configuration management database that contains all servers (physical and virtual) and relationship to business apps M

  1. Define CMDB Design Standards: Once goals are defined you need to set CMDB design standards that team should follow before initiating CMDB design or development efforts. These standards can be defined using ITIL and other leading practices. Below is a list of few design standards that you should consider:
    • Start small and iterate – Start with high priority CMDB use cases / goals and then leverage the success and lessons learned from them to expand to other medium/low use cases.
    • Bring in only necessary information (Leverage federation techniques) – For every data element you are planning to store in CMDB there needs to be a use case on how that information will be gathered and used. By using CMDB federated model you bring in only key information for running ITSM and other ESM processes to CMDB and for any additional information user is redirected to the federated data source.
    • Automate data gathering and population – No CMDB will ever be successful if it is not supported by automation for data population. You should consider discovery tools that can discover the CIs and relationships automatically. In addition to discovery tool consider other element manager which might be present in your organization e.g. SCCM is typically used by most organizations which stores windows type device information, which could be integrated with your CMDB to populate windows device information. Any manual data population should be a No unless there is a data owner assigned to populate it manually.
    • Clearly define CI ownership – Every CI needs to have an owner who should be primarily responsible for maintaining the CI information and its accuracy. It’s common to see IT playing the role of CI owner for the Infrastructure CIs. In addition, don’t forget the CI relationship ownership. If an application is related to a database who owns that relationship – app owner, database owner or both? Define it clearly in your standards.
  2. Define CMDB Logical Data Model: Now you have the goals that you want to achieve and the standards you need to follow, the next step is to define logical CMDB data model in order to identify which CI Classes, attributes and relationships are needed in your CMDB. You can divide this exercise into 2 parts as below:
    • CI Class and relationship definition: Begin with CI Class and relationship information gathering. One of the common approaches to do this is to pick your top 5 business services (If you don’t know your business services then pick top 5 business applications) and perform a top down approach to understand the CI classes that you need 
    • CMDB Logical Data Model
      e.g. A business service is dependent upon an IT Service, which may depend upon multiple applications, which are in turn dependent upon databases and servers. Ensure to tie this top down approach data modeling exercise with your CMDB goals and standards so that you stay within the boundaries and don’t go too granular. Below is an example of top down approach to understand the CI and relationships that are required.
    • CI Attributes Definition: Now you know which CI classes you need; the next step is to gather the CI attributes for the CI class E.g. For a Server CI class, typically you need Server Name, IP Address, FQDN, Support Group, Server Owner Group etc. While gathering CI attributes ensure to follow the goals and standards defined. Create a template to gather CI attributes level details (Such as below). Apart from gathering functional and technical information don’t forget to capture key information such as what will be the source of the data (Discovery or manual) and if it is manual then which team will be responsible to update it. This will not only help in understanding where the data will come from but also give you an understanding of the list of data sources that needs to be integrated with CMDB.

Server CI Attribute Description Source of Data Team Name (If Manual) Field Type Field Length
Name Server Name Discovery N/A String 255
Support Group Team that supports the server or where the incident tickets will be first routed Manual Server Team String 255

  1. Build CMDB: After first 4 steps you are ready to build your CMDB. In this step implementation of CMDB data model (i.e. develop CI classes, attributes and relationship in CMDB) will be performed in your organization’s ITSM platform and then followed by data population. You can divide this into 2 steps:
    • Develop CMDB platform: In this step the development team will build the CMDB based on the logical data model. That means they will create CI classes (Tables), CI attributes (fields) and relationships in your CMDB. Note this step is to create tables and fields etc. to store CMDB information, the actual data load will be done in next step.

  • Load CMDB data: In this step setup of Discovery and/or integration with other data sources (Such as SCCM, Other element managers) with CMDB is performed. Leverage the logical data model prepared in previous step to cross check list of all data sources that needs to be integrated. Note that data load is not a one-time activity as CMDB data should always stay current and accurate. So, ensure discovery and other import integration schedules are setup appropriately to gather CI information on regular basis as per your business needs. If any CI information is maintained manually this is the time to gather that information as well.

  1. Don’t Forget the Process: In the above steps we covered mostly the business and technical aspects associated with CMDB but let’s not forget about the processes required to implement and maintain CMDB. This step should be conducted in parallel to CMDB logical data model definition exercise, as platform will need to be built also according to the defined process. Following items must be considered for effective and end to end configuration management process:
    • Define process activities:
      • Process to create and update CIs and relationships – This should include end to end CI lifecycle i.e. Receive to Retire
      • Process to update CMDB data model – Includes how to create new CI classes or relationship types and process to bring in data for it.
      • Periodic audit process – This is an important step to ensure CMDB is regularly audited for its accuracy and completeness.
    • Define roles and responsibilities:
      • Clearly define roles and responsibilities needed for the configuration management process. Typically, these roles are: Configuration management process owner, configuration manager, configuration analyst, CI owners etc.
      • Ensure that each process activity is mapped to a role that will perform that activity
      • Define RACI for end to end configuration management process
    • Define process performance indicators:
      • Define key performance indicators (KPI’s) and Critical success factors (CSF’s) to measure process and CMDB on an ongoing basis. Some examples of key indicators to measure are completeness of the CMDB (Check % of mandatory field population), CMDB accuracy, % of Orphan CIs (You should not have CIs in your CMDB with no relationship unless they are non-operational) etc.
      • Leverage your ITSM platform to measure those KPIs and CSFs by creating reports and dashboard

Once above activities including process definition and CMDB build are done, it must be followed by following by testing, data validation and training specially to the CI owners.

  1. Continuous Improvement: The last step of the CMDB initiative is to continuously improve configuration management process and its CMDB. Below are some ideas to perform continuous improvement:
    • Measure the process: Leverage the KPIs, CSFs and other reports/dashboards established in the previous step to measure the effectiveness of the process and CMDB on continuous basis
    • Establish CI Owner Network: Create a CI Owner network and cadence with them. Core CMDB team should meet with CI owners on regular basis (Monthly, Semi Monthly etc.) to discuss any CMDB challenges, health status reports, gather feedback and any actions CI owners needs to take.
    • Stay in touch with leadership: Even though the initial CMDB implementation might be complete, CMDB team should still engage with IT leadership to showcase value of CMDB, effectiveness of the processes and also to understand any major IT initiatives in the pipeline that could impact CMDB, so that team can prepare ahead of time and support those initiatives.

The above steps are based on our experience working with multiple clients with their CMDB initiative. These clients are now reaping huge value from their CMDB success by supporting IT initiatives such as data center migration, application rationalization, cloud initiatives or supporting ITSM and ESM processes. We specialize in ITSM, CMDB, ITAM, and HR Service Management processes. If you have any questions related to the blog or need help with your CMDB or IT Asset Management implementation, you can reach out to us at

Implementing and managing CMDB is one of the most critical and complex tasks within ITSM program however a solid and mature CMDB can bring huge rewards for the IT....