As a soon-to-be father, I have been getting my head ready for the barrage of questions from my youngling when he starts to talk and question the world he is in. Listening to a well known radio commercial where the little girl keeps asking her father why, followed by why, followed by why, made me think even more.
The question might be asked, why am I waffling about why? Well, the answer is simple. I wish people were brave enough to ask this question in their day-to-day service management activities. And why specifically with regards to service asset and configuration management, or config management as it is called. Hopefully in the following paragraphs, you will get the gist of what I am pleading for.
The industry has progressed considerably and sanity is slowly prevailing. It has moved from having to develop the death star of all configuration management repositories, aka the CMDB, to an ecosystem of MDR (management data repositories) all working together for the common good, aka the configuration management system or CMS.
While the CMS looks bigger at first glance, it is actually a much more pragmatic approach to configuration management, or service asset and configuration management as it is known in ITIL v3.
Architecture is key
When approaching the development of a CMS ecosystem in an organisation, I cannot understate the importance of architecture. And architecture asks the why, and a lot more. Users must move away from taking the concept of the CMDB and then growing a CMS from there. They have to approach the business view (why), functional view (what), technical view (how) and then implementation view (with). So, a lot more questions than just why, but for me the why takes the nod.
The asset management repository contains a wealth of information on any configuration item.
Clive Brindley is a solution architect and pre-sales manager within the BTO business unit at HP Software + Solutions SA.
A simple example: Consider the development of a service desk platform to drive the standard incident, problem and change processes (there are others, but I said I will keep this simple for now). There is a lot of data that potentially needs to be stored to support the analyst in his or her decision-making process. Imagine that there is currently an asset management system, a service repository, a legacy CMDB, a compliance repository, an availability and performance management repository, and the list goes on. Now to add the service desk repository to this, and suddenly there is a large CMS, or is there?
What data is needed to pull into the service desk repository, be it static or dynamic federation, to support the analyst in making the right call when supporting the various ITIL processes? This is where users need to start asking the why. The asset management repository contains a wealth of information on any configuration item/asset, or in this example, a desktop: cost, depreciation, financial information and more. Is all of this needed in the service desk? Or would the service contract associated with a desktop be the appropriate information to federate? Now with this information, the analyst can make the call on whether or not to call the maintenance contractor or procure a replacement.
Working together
It is not CMS vs SACM. To manage large and complex IT services and infrastructures, service asset and configuration management (SACM) requires the use of a supporting CMS. Now the question may be asked, what is the value of having the same CI in multiple repositories, as described above? It is simple: each one of them supports a specific use case.
Another example would be the report required for the compliance and audit department. Are all my servers up to scratch and built according to the organisation's defined standards? I would go to the compliance repository and run the report, done.
But, if I were the same analyst working on a server incident, it would be great to know if the server was compliant, as this could be a reason for the incident (someone changing a setting, breaking the server and making it non-compliant in the process). Do I need all the data from the compliance repository in the service desk? Certainly not. I just need the one attribute, compliant or not. If I need more information, I punch out and get the data, but it is not stored in the service desk database. All of this was avoided because of asking why during the architecture of the solution, pushing back and asking the hard questions.
Share