Asset lifecycle
BMC Helix CMDB and BMC Helix ITSM are critical components of tracking an asset lifecycle throughout an organizations IT environment. Any organization adhering to ITIL principles will also find asset lifecycle to be a critical part of their IT services. Helix CDMB and BMC Helix ITSM, together, work to do just that. As an example, we're going to track three different assets through their lifecycles (Computer System, Software Product, and Service) and all of the key components that are required to set up these assets.
Foundation - CMDB and AR System server
The foundation on which any modern system is built, starts with a database. BMC Helix CMDB is no exception. If the database isn't sized correctly, configured correctly, or is inadequate in any way, then the entire system fails. In addition, BMC Helix CMDB and BMC Helix ITSM are both built on top of the AR System platform, which is a technology that interfaces with the database and processes that data. This combination is what allows CMDB and ITSM to be some of the most powerful tools in the industry.
CMDB is built on top of the AR System Server. The primary purpose of a CMDB is to house Configuration Items (CIs) that are used for configuration management. CIs can come in many shapes and sizes such as computer systems, software products, and services. A general rule of thumb to remember is, if it can be changed, it is probably a CI.
Key components in BMC Helix CMDB
BMC Helix CMDB has many components that make it so powerful including the ability to normalize data structures, automatically reconcile different sources of data, and simulate impacts between CI's and services.
This whole structure, in its entirety, is known as the CMDB.
A service is a logical representation of a Business Service that provides value to end-users. A service model is the representation of that service with all of the relationships between the service and the various components that make up that service.
This includes objects such as Software Products, Computer Systems, other hardware, and Infrastructure objects such as IP Endpoints. It can also include other objects such as other services.
The CMDB Engines, including Reconciliation Engine, Normalization Engine, Atrium Integrator, and Impact Simulator are a few of the key technologies that make CMDB so versatile and allow less human intervention.
Creating CIs in CMDB
Once a CMDB system is established, the next step is recording all of the CIs that are needed. The most simple method is manual entry of the data. This is where an end user logs into the CMDB Portal and manually enters all of the attributes for a CI, records its relationships, and then proceeds to keep up with all of the other components.
Example
A Computer System named Server001 is a server that is used to run the email server software Apache JAMES. This software runs our Enterprise Service, Email.
This is a simple example of a service model that will help understand the role of all components that go into making the entire asset lifecycle work.
The BMC Helix ITSM uses the CMDB as a part of Asset Management, with help from the other ITSM applications, to keep track of the asset lifecycle. Assuming that the information has been entered for each of our example CIs by an employee, we're going to look at the following CIs on their lifecycle:
CI | Details |
|---|---|
Computer System - Server001 | Once the computer system is saved in the CMDB, it goes through all of the processing that all other CIs would, including Normalization and Reconciliation. |
Product - Apache JAMES | Once the Product is saved in CMDB, it goes through all of the processing that all other CIs would, including Normalization and Reconciliation. |
Service - Email | Once the Service is saved in CMDB, it goes through all of the processing that all other CIs would, including Normalization and Reconciliation. |
All three of these CIs would need to be related to each other, but not directly. The proper relationships would be from Email to Apache JAMES. Then, Apache JAMES will have a second relationship back to "Server001". All of these put together make up the service model. In a live environment, the relationships will be more complex but will follow all of these basic principles. This is important to see how an outage of one link in this chain will impact the service itself. Once this information has been entered, it should look similar to the image on the side, in CMDB Explorer.
CIs and Product Catalog
Services, CIs, and CMDB are great tools but the value to a business comes when paired with BMC Helix ITSM. Asset Management has a direct relationship with CMDB because all Assets are recorded as a CI in the CMDB.
But another intimate relationship between a BMC Helix ITSM component and CMDB is with the Product Catalog.
In this example, our Product Catalog should have an entry for each type of CI that we have created, a Server, Software Product, and Business Service. This should look similar to a library of available products in our environment.
In a proper live environment, you might have hundreds of product catalog entries, but you will have tens of thousands of CIs. In this example, it will be 1-to-1 relationship between CIs and the product catalog entry. Notice how each is configured, this will need to match the exact values entered in the CI to pass Normalization. While normalization has the capability to create rules to automatically correct poor data entry, that is outside the scope of this example.
Computer System - Server001
Product Type | Hardware |
CI Type | Computer System |
Category | Hardware |
Type | Processing Unit |
Item | Server |
Manufacture | SuperServers |
Model | Super-A01 |
Product - Apache JAMES
Product Type | Software |
CI Type | Product |
Category | Software |
Type | Application |
Item | Enterprise Open Source |
Manufacture | Apache |
Model | JAMES |
Service - Email
Product Type | Service |
CI Type | Business Service |
Category | Service |
Type | Infrastructure |
Item | |
Manufacture | |
Model |
Consumption of BMC Helix CMDB data by other applications
Now that the data has been entered, proper relationships have been made, and all of the CIs have a status of Deployed, we can start making tickets in other applications against our new assets. This includes tickets such as Incidents. An example might be a new user, Bob, who is unable to access his email account that was just provisioned for him. The Incident ticket would be associated with the Email service, not the server or the installed software, as it is assumed they're working correctly. During troubleshooting, the Help Desk agent determines that Bob's account was locked and unlocks it and resolved the Incident. Such incidents occur many times during the life cycle of this Email service and the relationships will ensure that the effort used to keep the service running and operational, are tracked and never lost.
The following image shows a sample incident for this example:
Based on the example, the following image shows the relationship between CIs and service models:
After the Incident is created, if you proceed to open the Email service in Asset Management, you'll now see our new incident as a Related Item allowing all users to more carefully track the usages of their assets. This can be extremely powerful if used correctly.
Managers of the asset can track the ticket types against their services. Agents that support the asset can review a history of tickets to better understand new issues or better understand the status of new tickets.
In addition to incident tickets and other service desk operations, all other ticket types can also be related to these assets.
For example, a Change ticket can be made against Server001 to increase the memory on the system or to update a firmware. A Service Request might be made that is related to Apache JAMES to create new users. All of the ITSM applications can be related to each asset, as needed. Consider using the relations of ITSM tickets to assets because it is easy to relate the wrong tickets to the wrong assets which can cause bad relationships. Having mature business processes will help ensure that agents working on the ticket will be able to select the correct options with confidence.
This expansion will include all types of tickets, all of them together makes up IT Service Management. It should be noted that Change Request, Releases, Service Request, and all other types of tickets can be made to an asset without a requirement or dependency on another ticket type, unless dictated by a business process implemented by your organization. The following image roughly shows a representation of the IT Service Management environment:
After a functioning system has been established then considerations for keeping the CMDB updated from the IT Environment will need to be made.For example, every time that Apache JAMES is updated, are Change Coordinators required to update all of the CI details for the servers and software? This could be a way to handle it, but most environments that rely on human intervention eventually drift to the point where the level of confidence that CI data is correct isn't acceptable. This is where automation tools such as Atrium Integrator or BMC Discovery can be used to leverage automated scanning of assets connected to the network or other data sources such as spreadsheets, databases, and other systems. The following image represents the discovery sources creating CIs in the ITSM environment:
After the confidence level is high for the CI data, the quality of the data is complete, and there are regular processes in place to keep the data updated, then other automated products can be introduced to help automate other elements of your IT Business Processes, such as AI Operation Management. This allows for companies to track the attributes of CIs, the status of assets, and the lifecycle of all the work that went into the asset to better facilitate decisions made for the IT Environment. The following image roughly shows AI Operations Management consuming the ITSM and CMDB data:
