BMC Helix Remedyforce CMDB 2.0 architecture

BMC Helix Remedyforce Configuration Management Database (CMDB) enables you to implement both IT asset management and configuration item management in your environment. IT asset management entails collecting inventory, financial, and contractual data to manage the IT asset through its lifecycle. Configuration item management, on the other hand, entails tracking, managing, and auditing configuration items (CIs) in your IT environment that are critical to delivering a business service.

You can leverage BMC Helix Remedyforce CMDB to store information about the assets and CIs that you want to track in your IT environment, and the relationships among them. You can also link these CIs and assets to change requests, incidents, problems, releases, tasks, and knowledge articles.

Based on your requirements, you can choose to enable only IT asset management, only configuration item management, or both. For more information, see Configuring general BMC Remedyforce CMDB 2.0 settings.

The following topics are provided:

Coexistence of CIs and assets

CIs are any components in your IT infrastructure that are critical to delivering business services to your users (for example, a server tied to a banking application). Assets are corporate resources that you manage from an inventory, financial, and contractual perspective (for example, mobile phones). A CMDB instance represents a record in the BMC Helix Remedyforce CMDB, which can be classified as a CI (access point), asset (mobile phone), or both (server). Each instance has configurable properties or attributes that identify it as an asset, CI, or both. Because of this design, you are not required to duplicate data if a record is both a CI and an asset.

Classes and attributes

The Common Data Model includes CI, CI and Asset, Asset, and Rule Based Asset classes. Rule Based Asset classes have predefined conditions that are specified on a CI class, also referred to as the rule class. Specific CIs that meet the defined conditions are also dynamically classified as assets. For example, the out-of-the-box BMC_Laptop Rule Based Asset class has a predefined condition that also classifies BMC_ComputerSystem CIs whose Primary Capability attribute is Laptop as instances of the BMC_Laptop Rule Based Asset class.

The Common Data Model also contains the following attributes:

Common attributes that are available for all classes.
For example, Primary Client and Location.
Common asset attributes that are available for only CI and Asset, Asset, and Rule Based Asset classes.
For example, Asset Age and Asset Birthdate.
Attributes that are available for a specific class and its child classes.
For example, the BYOD and MEID attributes are available only for the BMC_Mobile asset class and its child classes.
Asset Status and CI Status attributes that are available for specific class types.
The Asset Status attribute is available for instances of Asset, Rule Based Asset, and CI and Asset classes. The CI Status attribute is available for instances of CI and CI and Asset classes.

For information about how these attributes are dynamically displayed in the Instance Editor, see Dynamic Instance Editor.

Dynamic Instance Editor

The Instance Editor form, which is accessed from the Remedyforce CMDB tab, enables users to manage instances of different classes. The following table lists the attributes that are dynamically shown in the Instance Editor based on the class to which an instance belongs.

Class type	Attributes shown in the Instance Editor
CI	Common attributes for all classes, such as Primary Client and Location. Class-specific attributes for the selected class and all its parent classes. CI Status attribute.
Asset	Common attributes for all classes, such as Primary Client and Location. Common asset attributes, such as Asset Age and Asset Birthdate. Class-specific attributes for the selected class and all its parent classes. Asset Status attribute.
Rule Based Asset	Common attributes for all classes, such as Primary Client and Location. Common asset attributes, such as Asset Age and Asset Birthdate. Class-specific attributes for the rule class and all its parent classes. For example, if you are creating or editing an instance of the `BMC_Laptop` class, class-specific attributes of the `BMC_ComputerSystem` and its parent classes are shown. Asset Status attribute. (If accessed from the All* tab in the CMDB list view)* Additional CI Status attribute.
CI and Asset	Common attributes for all classes, such as Primary Client and Location. Class-specific attributes for the selected class and all its parent classes. (If accessed from the CI tab in the CMDB list view) Additional CI Status attribute. (If accessed from the Asset* tab in the CMDB list view)* Additional common asset attributes and the Asset Status attributes. (If accessed from the All* tab in the CMDB list view)* Additional common asset attributes along with the CI Status and Asset Status attributes.

For more information, see Overview of the Remedyforce CMDB tab.

Relationships

Assets and CIs do not exist in a vacuum; they are related and affect one another. Relationships can be simple, such as a disk drive being a component of a computer system, or more complex. Relationships exist not only between CIs and assets, but between CIs and other CIs, and assets and other assets.

Relationship data makes the CMDB a powerful decision support tool. Understanding the dependencies and other relationships among your CIs and assets can tell you how upgrading Processor A can improve Laptop B's performance, or which services are affected if Router C fails. Most down time is caused by issues stemming from configuration changes. Accurate relationship information can help you prevent those issues. The use of relationships is a feature that differentiates a CMDB from an asset store.

The CMDB Explorer is the BMC Helix Remedyforce data visualization tool. When you launch the CMDB Explorer for a CI or asset, it displays its related CIs and assets and their interrelationships in an easy-to-understand, graphical manner. For more information, see Working with the CMDB Explorer.

Asset Management and CI Management views

Although both assets and CIs are stored in BMC Helix Remedyforce CMDB, views can control what is shown to different users. For example, only assets can be shown to a few users, only CIs to another group of users, and both CIs and assets to yet another group of users.

The Asset Management View and CI Management View options assigned to users control display of the following items on the Remedyforce CMDB tab:

Classes that are shown in the CMDB list view
Relationships that can be created from the Relationship Editor
Relationships that can be viewed in the CMDB Explorer

Views also control the actions that users can perform on the Remedyforce CMDB tab. For example, only a few users can edit and delete CIs and assets, while other users can only view assets or CIs.

For more information, see Managing Remedyforce CMDB user permissions.

CMDB Common Data Model

The Common Data Model in BMC Helix Remedyforce CMDB unifies the representation of asset and CI data. It is designed to store data about the most common CIs and assets and provide a mechanism for linking them. The data model provides a complete view of all elements of an IT environment and how they affect each other.

The data model is object oriented, which means that it has a hierarchical set of classes in which each class inherits attributes from its superclass–the class above it in the hierarchy–and then adds its own attributes to create a more specific type of object, a subclass. The benefits of an object-oriented data model include enforcement of common attributes among similar types of CIs or assets, and the ability to search within not just a given class of CIs or assets, but within any branch of the hierarchy. From a base class from which all others are derived, you can search for all CIs and assets or all relationships.

Classes in the Common Data Model are intended to represent the physical, logical, and conceptual items that all IT environments track in a CMDB. A class has one or more attributes, each of which specifies a property of the class. For example, BMC_ComputerSystem has attributes such as Host Name and Domain, and BMC_Mobile has attributes such as ICCID and BYOD. A class can be of the following types:

Class type	Additional information
CI	None
CI and Asset	None
Asset	None
Rule Base Asset	Defines a type of asset that is also a CI.
Relationship	Defines a type of relationship between two specific CI classes. An instance of the relationship class relates an instance of the first, or source, CI or asset class to an instance of the second, or destination, CI or asset class. The two instances are considered to be members of the relationship.
Abstract	Has attributes, but you cannot create instances of this class. It exists only to organize subclasses, enabling you to add a layer of organization.

You have many different types of CIs and assets. Without a data model that accurately reflects these types and the types of relationships that can exist between CIs, your CMDB might store attributes that do not pertain to their CIs and assets, leave out necessary attributes, and make it harder to search for groups of CIs and assets

Click here to see the hierarchical diagram of all classes in the Common Data Model (CDM), including unique attributes. The BMC Helix Remedyforce CMDB Common Data Model section also provides detailed information about classes and attributes in the CDM.

CMDB data storage

CMDB 2.0 provides a flattened structure to store CIs and assets. All the CI and asset records are saved in one table (or object), Base Element. Different field sets, corresponding to the CMDB classes, are provided in the Base Element object. For example, for the Computer System class, the Computer System field set is provided in the Base Element object. However, records of all CIs and assets are saved in the Base Element object.

Hierarchy in classes is maintained by using the CMDB_Class object.

The following points describe how object-oriented architecture is implemented:

Each class is implemented as a field set in the Base Element object.
Each attribute is implemented as a field in the Base Element object. The following points describe how attributes are grouped in the Base Element object:
- Attributes that are common for all classes are grouped in the Base Element field set in the Base Element object.
- Attributes that are common for all asset classes are grouped in the Asset Common Attributes field set in the Base Element object.
- Fields that are specific to a class are grouped in the field set of the class, for example Mainframe.
The class hierarchy is implemented by using the CMDB_Class object.
For each class, an entry is created in the CMDB_Class object that identifies the hierarchical level of the class in the CMDB.

The Instance Editor form, which is accessed from the Remedyforce CMDB tab, enables users to manage instances of different classes. The following points describe fields that are shown on the General and Specifications tabs in the Instance Editor:

General—All fields from the Base Element field set are shown. The fields in this field set are common for all CIs and assets. For instances of the Asset, Rule Based Asset, and CI and Asset classes, all fields from the Asset Common Attributes field set are also shown after fields from the Base Element field set.
Specifications—Fields from the class-specific field set and the field sets of all of its parent classes (excluding Base Element) are shown.
For example, in the hierarchy of Base Element > Systems > Computer Systems > Mainframe, on the Specifications tab of a Mainframe record, fields are shown from the Mainframe, Computer System, and Systems field sets.
Note

In the case of Rule Based Asset classes, class-specific attributes for the rule class and all its parent classes are shown on the Specifications tab.

The following figure shows the Instance Editor for a Mainframe record.

Note

When you are adding a field to a field set, if you have a Lookup-type field (to another object) in the Available For Field Set list, do not add fields of the Lookup-field object to a field set of the Base Element object. For example, if you have a Lookup field to the Incident object on the Base Element object, do not add the Incident object fields to the field sets of the Base Element object.