Skip navigation

BMC Helix

4 Posts authored by: David Gaunt
David Gaunt

What is a CMDB?

Posted by David Gaunt Mar 17, 2018
Share This:

Have you ever wanted to know what a CMDB is and the benefits it can provide? This blog will provide a straight forward overview of its meaning a purpose


Firstly, CMDB stands for – Configuration Management Database. This is a simply a repository of data that acts as a data warehouse for Information technology(IT) information. The CMDB holds data relating to a collection of IT assets (commonly referred to as configuration items (CI)), as well as to descriptive relationships between such assets. The repository provides a means of understanding:

  • the composition of critical assets such as information systems
  • the upstream sources or dependencies of assets
  • the downstream targets of assets


Purpose and Benefits

CMDBs are used to keep track of the state of assets such as products, systems, software, facilities, and people as they exist at specific points in time, as well as the relationships between such assets. The maintenance of such state related information allows for things like the reconstruction of such assets, at any point in their existence, as well as for things such as impact analysis, in the cases of root cause analysis or change management.

A CMDB helps an organization understand the relationships between the components of a system and track their configurations. The CMDB is a fundamental component of the ITIL framework's Configuration Management process. CMDB implementations often involve federation, the inclusion of data into the CMDB from other sources, such as asset management, in such a way that the source of the data retains control of the data. Federation is usually distinguished from ETL (extract, transform, load) solutions in which data is copied into the CMDB.

CMDBs can be used for many things, including but not limited to business intelligence, software and hardware builds, and impact analysis for both change management[1] and incident management.

In the context of ITIL the use of CMDBs as part of infrastructure operations and support. The CMDB represents the authorized configuration of the significant components of the IT environment.


The CMDB contains and records data that are also called configuration items (CI). It also provides details about the important attributes of CIs and the relationships between them.

CI attributes and data

Depending on the CI type or category, there are many attributes that might be captured:

  1. 1. CI Unique Identifier or Identification Code
  2. 2. CI Name or Label (often, both, long names and short names)
  3. 3. CI Abbreviations or Acronyms
  4. 4. CI Description
  5. 5. CI Ownership (organizations and people)
  6. 6. CI Importance

There can be many more, depending on the CI types. In some cases, there may be hundreds of attributes.

Because attributes are defined by metadata, CMDBs also contain metadata, and thus the concept overlaps with that of a metadata repository, which is also used to more effectively run IT organizations. Configuration management addresses how the data is to be kept up to date, which has historically been a weakness of metadata repositories.

Share This:

Do you ever wonder what are the difference between Service Requests, Incidents, Change Requests, Problem Records and Work Orders. This blog provides the official ITIL definitions.


Service Request: This is a user request for information or advice, or for a standard change. This is a pre-approved change that is low risk, relatively common and follows a procedure, or for access to an IT service. A great example of a standard request is a password reset.


Incident: An unplanned interruption to an IT Service or reduction in the quality of an IT service. Failure of a configuration item that has not yet affected service is also an incident.


Change: Request for Change (RFC) A formal proposal for a Change to be made. An RFC includes details of the proposed Change, and may be recorded on paper or electronically. The term RFC is often misused to mean a Change Record, or the Change itself.


Problem: A cause of one or more Incidents. The cause is not usually known at the time a Problem Record is created, and the Problem Management Process is responsible for further investigation.


Work Order: Used for the installation of an application, system or infrastructure component, typically issued from Release Management




These definitions form part of the ITIL Service Operation Process which encompasses the day-to-day activities, processes and infrastructure responsible for delivering value to the business through technology


Additional information can be found at - ITIL: The Beginner's Guide to Processes & Best Practices - BMC Software

Share This:

This simple blog is aimed to provide Remedy as a Service (RaaS) users a quick guide to understanding Service Level Agreements. The below table describes BMC's published Initial Response SLA’s.




Initial Response Targets


24 hours a day, 7 days a week (including published holidays)

15 Minutes


Local business hours: 7:00 AM to 7:00 PM, Monday to Friday (excluding published holidays)

30 minutes


Local business hours: 7:00 AM to 7:00 PM, Monday to Friday (excluding published holidays)

4 business hours


Local business hours: 7:00 AM to 7:00 PM, Monday to Friday (excluding published holidays)

16 business hours


Severity 1: Critical Service Impact

Case critically affects the primary business service, major application, or mission critical system. Customer resources should be available and willing to work on a 24x7 basis with BMC to resolve the case. Characteristics of a Severity 1 case include:

  • Business Service is not operational
  • Production system crashes
  • Data integrity at risk
  • Production backup and recovery operations fail.

Severity 2: Significant Service or Implementation Impact

The Business Service, major Application, or a system is seriously affected or implementation stopped. No acceptable workaround is available.

Severity 3; Moderate Service Impact

The Business Service, major Application, or a system is moderately impacted, no data has been lost, and the Business Service, Application, or system is still functioning. The case may be temporarily circumvented using an available workaround.

Severity 4: No Service Impact

Non-critical cases, general questions, enhancement requests, or documentation cases


  For more information refer to

Share This:

Preparing for an OnDemand Upgrade


Upgrades to your OnDemand environments are performed by BMC’s SaaS operations team and it is important to be prepared for the project to be successfully completed.

There are a number of steps required from both customer and BMC. Before proceeding with the project is it important to be aware of the new features and function contain in the new release.


As you begin to think about an upgrade, discuss with your BRM a position to secure in the upgrade queue where the schedule gives you sufficient time to go through planning and prerequisites. Requesting an upgrade via either of these methods.

  • Submit a request through the BMC OnDemand Service Desk ( using the 'Request an ITSM Upgrade' option in the portal stating required dates.
  • Work through your Business Relationship Manager (BRM) to coordinate a start date that is convenient for you.

Be prepared

  • Detailed upgrade documentation is available from your BRM upon request. A review of this documentation will help you understand what is required from your end and help you make a decision on project scheduling.
  • Allow up to a 3 month project time line when considering a start date.
  • Is there anything unique about your environment?
  • Do you require any BMC expertise to understand any of the new features/functions?
  • Identify any customizations you have implemented.


Roles and responsibilities


  • Finalize that requested dates are available.
  • Supply reference documentation including customizations and UAT documentation.
  • Provide new release documentation (including enhancements, corrected and open issues, webinars and FAQs)
  • Provide detailed project plan


  • Confirmation of requested dates
  • Agree to key milestones for upgrade start dates and starting and completing user acceptance dates.
  • Return any pre-req documentation when requested
  • Commit to testing resources for UAT and ensure tester are available when required.
  • Make sure all stake holding are aware of the project timelines
  • Sign off on major completed milestones


Once these tasks have been completed the upgrade process will begin at the requested date. Weekly progress meeting will take place with the upgrade team to make sure the project is on track.

On successful completion of the project the upgrade team will provide 1 week hyper-care after which time any new problems/Incident that are encountered will be handled by the normal support teams.

For additional information on the upgrade policy and process you can refer to

BMC OnDemand Upgrade policy - BMC Remedy OnDemand Subscriber Information - BMC Documentation

Filter Blog

By date:
By tag: