[Posted by site admin in George's absense, filled by email] My previous post on Monday referred to what should be in the CMDB, and in particular I mentioned virtual Configuration Items.
When starting with a CMDB, a lot of Service Desk/Helpdesk professionals seem to focus on ‘tangibles’ – server hardware, network devices such as routers, and network links such as ADSL and MPSL. Whilst worthy, these may only tell half the story.
Suppose that you have a server computer called ‘ROMA’ on your network that runs a SQL Server database and a web server running a .NET application. This computer ROMA is recorded in the CMDB – namely, you record what type of machine it is, how much memory is has, it’s maintenance details and so on. However, you need to address in a structured way the question ‘what does this machine do’ or ‘what is it’s business role’.
All too often, this is recorded in comments. A better approach, particularly with ITSM systems like Serio that display the CMDB graphically, is to create virtual Configuration Items (I’ll post a definition of the CMDB shortly). These are Configuration Items that you can’t touch, but do exist and add business value.
In the case of ROMA, you might create 3 new Configuration Items (CIs).
CI for the SQL Server database instance
CI for the Web Server
CI for the .NET application
What you would then do is link these together (the quickest way to do this in Serio is via copy & paste). The SQL Server CI is linked to ROMA, the Web Server CI is linked to ROMA, and the .NET application is linked to the Web Server. Of course, you can add additional links and dependencies onto the CMDB if that is how you perceive the interdependencies.
Doing this adds real value to the CMDB in many ways. For instance, looking at ROMA you can now see information about the components in provides into wider IT systems, and your new virtual CIs can themselves carry richer information such as recovery procedures.