How to design a CMDB in the cloud era

IT organisations should design practical configuration management databases that leverage the power of cloud to ensure that service availability targets are met in a cost-effective manner, writes IBRS’ Dr Wissam Raffoul

Since 1994 many Australian IT organisations have been implementing configuration management practices. However, it has been done with limited success when assessed against the key objectives of configuration management process and its associated database (CMDB) in terms of service availability and configuration items interdependencies.

IT organisations should review their configuration management plans in view of the latest public cloud offerings and adopt a phased implementation approach.

CMDB has two key objectives. Firstly, to improve service availability by understanding the configuration items inter-dependencies, thereby avoiding unscheduled outages when software updates are installed. Secondly, to expedite service rollout and simplify its ongoing management. However, the following critical issues faced IT organisations:

  • CMDB software selection and rollout difficulties. In some instances, the rollout took over six months at an upfront cost up to $500,000.
  • Ensuring quality configuration management contents. For example, a 2,500 user organisation would require a CMDB of 40,000 configuration items (based on CMDB design experience). This size made the items interdependencies determination a very difficult matter.
Failing to address these critical issues has left IT organisations with no alternative but to implement CMDB for different reasons, such as detecting stolen assets and issuing financial reports such as depreciation.

While the financial reports were useful for outsourced organisations (as it allowed them to verify outsourcing service providers’ charges) the key objectives of configuration management of high availability and simplified service management remained mostly unachieved.

With the recent availability of ‘configuration-as-a-service’ in the cloud market, CMDB’s high rollout cost and its inability to simplify management were fundamentally resolved. For example, there is no upfront cost – organisations are charged on a pay-as-you-go basis depending upon the number of resources and configuration changes made.

Furthermore, once connections to the cloud service are made, the IT organisation’s configuration items will be automatically identified and changes made will be recorded. Access to up-to-date information is available for any recorded item.

While the configuration-as-a-service is attractive in terms of its readiness to use, no upfront investment, and ease of management, there is still a need to control the ongoing cost should the CMDB grow. This can be achieved by initially focusing on mission critical systems only.

The number of configuration items per critical system does not exceed 300 items in the majority of cases. Hence, for the top three mission critical systems of a 2500 user organisation, CMDB of 40,000 items will be reduced to 900 items, thereby creating a strong foundation for cost control.

Whether IT organisations wish to use the Cloud or build an in-house CMDB service, the following building blocks should be addressed to ensure practical and cost effective implementation.

1: Define the CMDB logical data model – It should include the following entities:

  • Environment – links the configuration item to its environment such as production, pre‑production testing, disaster recovery, development
  • Financials – Defines the configuration item Total Cost of Ownership, age and location
  • Hardware – Defines all types of equipment and their dependencies (i.e. mobile devices, desktop, server, storage, network, printers, power supplies)
  • System software – Defines operating systems, database management systems and third-party tools and their dependencies
  • Applications – Defines application architecture layers such as external access, internal user access, presentation layer, integration layer, application logic layer, database layer and dependencies
  • Service levels and service partners agreements (SPA) – Defines key service level metrics including availability, reliability, support coverage, performance during peak periods, incident management, call waiting time, call abandonment rate, first call resolution rate and dependencies
  • Documentation – Defines service documentations including policies, procedures, architecture and dependencies
  • Contracts – Links configuration items to all associated service contracts covering licenses, outsourcing, managed services, cloud and maintenance
  • Dependencies – Defines the major item interdependencies including applications, system software, hardware, stakeholders, contracts and SPA
  • Stakeholders – Defines the stakeholders using and/or supporting a configuration item
  • Process Metrics – Defines the metrics that should be measured, analysed and improved
  • Role-based Access – Defines the roles that can access the CMDB
2: Define the configuration management process – It should cover the following process workflow phases:



  • Procurement – Prior to configuration items procurement, defines the desired service levels, service continuity requirements and estimates the Total Cost of Ownership
  • Setup – Defines how configuration items should be set up, monitored and supported
  • End user delivery – Defines how configuration items should be made available to end users and how service levels are tracked
  • Support – Aligns configuration items support activities with the agreed service levels
  • Audit – Defines how configuration items will be audited in accordance with IT organisations’ and service providers’ policies where applicable (e.g. In the case of Managed Services)
  • Retirement – Defines configuration items’ retirement policies
  • Review – Reassesses the usefulness of the CMDB after major changes to the service delivery architecture
3: Define process metrics – In addition to the traditional inventory lists that CMDB usually produces, it is critical that IT organisations monitor metrics that are directly related to service quality such as the following:
  • Percent Configuration Items (CIs) due for retirement
  • Percent incidents resolved by the aid of CMDB
  • Percent problems resolved by the aid of CMDB
  • Percent CIs not audited
  • Percent CMDB updates resulting from Business Continuity tests
4: Develop high-level implementation plan – It should cover the following:
  • Technology sub-plan – Defines how the CMDB should be rolled out, either in-house or in a public Cloud environment
  • Process sub-plan – Defines how the configuration management process is built, in accordance to point 2 above
  • People sub-plan – Maps the configuration management activities to the organisational structure and defines new roles and responsibilities covering configuration management lifecycle where applicable
  • Risks – Identifies and mitigates the risks associated with the CMDB rollout
  • Cost – Estimates CMDB rollout and the ongoing cost
Next Steps:

It is recommended to:

  • Define the interaction with CMDB as per the following example:
  • Interview the current configuration management practitioners to assess the maturity of the existing configuration management process
  • Run CMDB Design workshop(s) to define CMDB implementation scope in terms of data and functionality
  • Run process workshop(s) to define the Configuration Management process gap between the existing and future states, roles and responsibilities and implementation directions (e.g. ITIL v2 or ITIL v3)
  • Run Process Metrics workshop to define process metrics, current data sources and how to make the desired CMDB the single point of truth
  • Get the CMDB rollout plan sponsored by a senior executive


Dr Wissam Raffoul specialises in transforming IT groups into service organisations, with particular expertise in IT Service Management (ITSM), process optimisation, outsourcing and cloud strategies, enterprise systems management solutions and business-centric IT strategies.

Prior to joining IBRS in 2013, he was General Manager strategic consulting in Dimension Data advising clients on applying technology to improve business performance. He was also formerly a vice-president in Gartner /META Group and issued various research publications covering service delivery processes, centre-of-excellence models, managing outsourcing vendors, benchmarks, maturity models, IT procurement evolution and supply/demand models.

In previous positions, he headed HP ITSM consulting Practice in Australia. He also acted as an infrastructure manager, reporting to the CIO at a number of large organisations in government and in the financial and petrochemical industries.

Join the Computerworld newsletter!

Error: Please check your email address.

Tags configuration management softwareCloudcloud computingconfiguration management

More about Dimension DataGartnerHPIBRSTechnology

Show Comments