BMC Remedyforce CMDB 2.0 architecture
BMC 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 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 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_Mobileasset 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.
|Attributes shown in the Instance Editor
|Rule Based Asset
|CI and Asset
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 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 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 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:
|CI and Asset
|Rule Base Asset
|Defines a type of asset that is also a CI.
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.
|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 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),
Element. Different field sets, corresponding to the CMDB classes, are provided in the
Element object. For example, for the Computer System class, the Computer System field set is provided in the
Element object. However, records of all CIs and assets are saved in the
Hierarchy in classes is maintained by using the
The following points describe how object-oriented architecture is implemented:
- Each class is implemented as a field set in the
- Each attribute is implemented as a field in the
Elementobject. The following points describe how attributes are grouped in the
- Attributes that are common for all classes are grouped in the Base Element field set in the
- Attributes that are common for all asset classes are grouped in the Asset Common Attributes field set in the the
- Fields that are specific to a class are grouped in the field set of the class, for example Mainframe.
- Attributes that are common for all classes are grouped in the Base Element field set in the
- The class hierarchy is implemented by using the
For each class, an entry is created in the
CMDB_Classobject 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.
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.
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
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.