In the first post in this series, I gave the basic differences between assets and configuration items. In this concluding piece, I will provide the differences that exist when there is a need to govern changes to it.
Configuration items and assets carry different priorities in terms of their worth for the organization. Let’s consider the example of a server as a configuration item and a laptop as an asset. If the server was to go down, the business impact caused as a result is bearing. It could bring down services that will possibly affect a number of users. Likewise the business impact of a laptop going down will impact the user of the laptop.
Comparing the two scenarios, it can be concluded that the manner in which configuration items and assets are governed and controlled must be dependent on their business impact/value.
I will highlight a couple of areas that differentiate configuration items from assets.
Level of Scrutiny for Making Changes
Whenever you make changes to configuration items, you generally go through the change management process.
The advisory body within the process will provide the approval based on the change justifications, and the precautions that you have undertaken. The approval also comes with the rider that it needs to be performed at a particular date and time.
Unless the approval is provided, there is no compliant way to make changes to configuration items. When I say changes, I refer to various types of changes that you might bring in – such as configuration changes, additions and deletions of Cis.
Must Read: Should CMDB and ADB be Merged?
This strict control is in place because any unsupervised changes could lead to service outage, which in turn could result in the business impact – financial, legal and perception.
For assets, there is no such scrutiny because there is hardly any impact if things were to go south. If a change is done in the form of an application installation, and if the installation was to fail, the impact is hardly felt – except for the user using the laptop.
Normally changes to laptops are done on the back of service request or incident tickets. In most organizations, users themselves have the admin or super-user access, allowing them to do whatever they want to, without the backing of approvals or ticket logs.
Finger on the Pulse
Configuration items are actively monitored using tools such as Splunk and Appdynamics. The monitoring activity ensures that the CI works as expected across the clock. Any anomalies get reported to appropriate teams to take action.
Most types of configuration items are monitored for availability, capacity and security. Just as in the case with changes, any issues pertaining to availability, capacity and security can potentially bring down the services. So, it is imperative that the critical elements of the service (read CI) is kept under constant supervision.
It is needless to say that assets are not monitored as the worst possible scenario with it breaking down is the loss of work related activities for the associated user.
To Conclude
I hope in this two-article series I have answered the questions that you might have around configuration items and assets. The Service Asset and Configuration Management process is wide, deep and varied. With my extensive experience around CMDB and asset management implementation, I hope to churn out more articles around the process, and the nuances that surround it.
