Asset Management is the set of activities or processes that are accountable for physical assets throughout their useful lives – from cradle to grave. Asset management is responsible for tracking and reporting the value and ownership of assets, including financial considerations.
Configuration Management is focused on the current state of an item - it’s availability, and capability to perform in support of an IT Service, as well as knowledge of combinations of items at any given time, working together to support an IT Service. The Configuration Management Database (CMDB) is the managed repository of these items, known as Configuration Items (CIs) that serves as the data source for Configuration Management activities.
Configuration, CMDB and Asset Management work together to form one system of accurate and timely decision-making data required to create, manage and deliver quality IT services.
Configuration & CMDB
Many IT organizations have not been very successful with Configuration Management & the CMDB. In most cases, this is because the efforts have been “a solution in search of a problem.” IT has taken a “
Unfortunately, those providing IT services didn’t see how to use the data, had limited ability to understand what data they might need, or how the data might relate to other data in the repository, or even more simply – what combinations of the data actually support their given service. Beyond that, there is significant complexity in the data caused by the wide variety of automated and manual, conflicting and duplicative sources of data, further compounded by the huge volume of data (CIs) that IT typically has accumulated in the CMDB.
How can this problem be solved? At Evergreen we take a
Top down, we begin by clearly identifying areas where accurate configuration data can have a significant,
Working with these service owners, we determine what challenges they face in delivering their service, and what decision support data would improve their ability to meet these challenges. Working down, we then identify the smallest set of data (not the largest) in a Pareto fashion (80/20) that can meet their needs – layer by layer, sub-service by sub service. By the time we reach the bottom (the CIs needed), we have the smallest defined dataset possible. Then bottom up - with this smaller set of data, we clean it – removing conflicting and duplicative information, and define the “golden source” or best, most accurate source for this data going forward. Last, we map it from top to bottom, understanding the relationships of the items and their criticality for supporting the service.
Doing this for two or three tier 1 services well, whether you call it a pilot or not, establishes a process & methodology for getting value from configuration management, builds a common understanding and experience base for the team delivering it, helps clarify the least rather than the most data needed for success, and creates a small but vocal customer base in the tier 1 application owners, which promotes and proves the success. All of which then sets the stage for successful,