CMDB architecture

The BMC Helix CMDB provides the features that you need to implement a CMDB in your environment. Any application that is integrated with BMC Helix CMDB (for example, a data provider like BMC Discovery or a data consumer like BMC Helix ITSM: Asset Management) can access the data from a centralized database.

• CMDB plug-ins
• Atrium Integrator

The following image represents the flow of data into CMDB:

For information about how CMDBis placed along other BMC Helix ITSMapps and REST APIs within the Remedy solution architecture, see  BMC Helix IT Service Management deployment architecture .

The following points explain the architecture:

• At the center of BMC Atrium Core is BMC Helix CMDB. BMC Helix CMDB uses a federated data model, featuring a centralized database linked to other data stores, to share configuration data without the high setup and maintenance costs associated with a pure centralized approach.
• The data inside BMC Helix CMDB consists of configuration items (CIs) and the relationships among them. A CI is a physical, logical, or conceptual entity that is part of your environment and has configurable attributes.
• Each CI or relationship is stored in a particular dataset within BMC Helix CMDB. Data from each source or discovery tool is organized into datasets, which are then reconciled so that one production dataset represents your environment. A dataset can store data from a particular provider, a snapshot of data at a particular time, or any other set you want to create.
  
  The Sandbox dataset is an overlay dataset for the BMC Asset dataset that allows you to make changes in a separate partition without changing the production data and without duplicating the entire dataset. The Sandbox functions as a control mechanism so that BMC Helix CMDB is not overloaded with unintended data when multiple sources update the BMC Helix CMDB.
• When CIs and its CI Relationships are added (manually, imported, automation, etc.) into the BMC Helix CMDB, each entry is assigned to a particular dataset identifier. This dataset identifier defines the specific source of information (data provider) that provided the CIs, its attribute data, and relationship connections.
  For example, CIs and its relationships discovered from BMC Discovery have BMC.ADDM as the dataset identifier. When the CI information of the discovered CIs is reconciled against other dataset identifiers, it is stored into a Golden dataset identifier of BMC.ASSET, thus allowing data consumers to access the trusted and most accurate data.
  
  In addition, the Sandbox dataset identifier represents an overlay dataset for the BMC.ASSET dataset identifier, which allows CMDBmanagers to define comparison requirements against the Production (BMC.ASSET) dataset identifier before the changes are incorporated into the CI record. This allows Change Managers to be notified of changes made to a CI, thus giving them the opportunity to ensure a Change Request was submitted and approved to support the modification.

• The Normalization Engine makes sure that data from different data providers is consistent in BMC Helix CMDB. After data is normalized before or after it is created in a dataset, it can be reconciled and saved to the BMC Helix CMDB production dataset.

  Note

  BMC recommends that you normalize data before reconciliation.

• The Reconciliation Engine merges data from multiple import datasets into the BMC Asset dataset. This consolidated view of your data is the production dataset that data consumers should use and on which you should base business decisions. The Reconciliation Engine also performs tasks such as deleting or purging records on a scheduled basis, comparing data for reporting or for AR System workflow triggers, and copying datasets into other datasets to protect the data.
  
  BMC Helix ITSM: Asset Management displays data from the BMC Asset dataset by default. If you manually edit data using BMC Helix ITSM: Asset Management, you should save those changes to the BMC.ASSET.SANDBOX dataset rather than writing them directly to the BMC Asset dataset, thereby enabling the changes to be reconciled with those from all active import datasets.

Open access to data in BMC Helix CMDB

Even the most accurate data is useless if you cannot access it. A wide variety of users and applications must be able to both read and write to the CMDB. Providers create and modify data in bulk, whereas consumers view the data and can also make modifications. The following figure shows some providers and consumers of BMC Helix CMDB data.

 Data providers and consumers

Open access to data includes these features:

• Programmatic access — BMC Helix CMDB provides C, Oracle Java, and web services application programming interfaces (APIs) to view and modify its data. This includes both instance data and the data model. For more information, see Developing.
• Bulk data load — BMC Helix CMDB provides ways to import multiple instances at once, so that discovery applications and others can rapidly populate the database: the BMC Helix CMDB APIs and Atrium Integrator. The latter maps and transfers data from multiple database and file formats into BMC Helix CMDB. For more information, see Importing data with Atrium Integrator.
• Database and platform independence — BMC Helix CMDB is compatible with multiple operating systems and database vendors to provide flexibility in your environment.

Data partitioning in BMC Helix CMDB

Partitioning is dividing your configuration data into subsets, each representing a logical group of configuration items (CIs) and relationships. In BMC Helix CMDB, these partitions are called datasets. The same real-world object or relationship can be represented by instances in more than one dataset. For example, different discovery applications can create CI and relationship instances in different datasets. You can later merge those instances into a single production dataset.

This is important for the goal of verifying and correcting configuration records against the infrastructure. You can create one dataset representing your intended configuration, then use a discovery application to create another dataset representing your actual configuration, and verify the former against the latter.

Federated data model

BMC Helix CMDB uses a federated data model, which means that you can keep some data in managed data repositories in lieu of populating BMC Helix CMDB with all your data. The most common types of federated data are related information and detailed attributes. Related information is information about a configuration item (CI) that does not itself qualify as a CI and therefore should not be stored in a CMDB. Detailed attributes are attributes of CIs stored in BMC Helix CMDB, but they are attributes that are not important enough to track at the level of a CMDB.

For related information, your CI records for software instances might link to the URL of an intranet page where the software license is posted, or each CI record might link to information necessary to search a problem database for all problems concerning that CI.

For detailed attributes, the CMDBrecord for an employee might have a Skills attribute that contains a list of the employee's skills and a Department attribute that contains the employee's department name. It might also link to an HR database where additional attributes, like Salary, that are not really important from a configuration perspective are stored.

Federated data might be stored in a discovery database, a Capacity Management system, an Availability Management system, or other external data stores. You can retrieve federated data and view it with CMDB Explorer, as if it were stored in BMC Helix CMDB. The BMC federated data model enables you to connect to Java database connectivity (JDBC) compliant databases and AR System forms.

CMDB Web Services and service oriented architecture

CMDB Web Services application programming interfaces (APIs) are modified based on the service oriented architecture (SOA). SOA facilitates the loose coupling of product integrations, minimizing the cost and difficulty of upgrading components.

Operations are grouped by related services. This grouping of operations enables services to be versioned and extended independent of each other, which makes it easier to add new services and operations.

With web services, integrations are more robust because services can be located anywhere and can be started or stopped without breaking the integration. For more information about web services and service oriented architecture, see Getting started with BMC Atrium Core Web Services.

User access to BMC Helix CMDB

To give someone access to BMC Helix CMDB, you must create a AR System user on the server where CMDB is installed. You can then make that user a member of multiple groups and assign those groups to roles that allow access to different parts of the application and its data. For detailed information about user access, permissions, and roles, see Managing permissions in BMC Atrium Core.

Virtualization management in BMC Helix CMDB

A benefit of virtualization is a dynamic IT environment in which changes can happen rapidly and frequently. However, this can also cause service models to be out of sync just as quickly.

These BMC Helix CMDB features avert issues that arise in a virtual environment:

• Continuous, real-time normalization and reconciliation to rapidly update data in BMC Helix CMDB
• Dynamic service model updates based on queries and templates
• Data models that represent virtual machine (VM) resource pools and settings
• Rapid data loads