Hello Felix

The model you suggested looks very sound, and very detailed. From a totally theoretical point of view, if you are considering things like fans etc as CIs, then creating impact relationships from memory and processor CIs would also seem important.The value of these is both for configuration purposes (knowing what the details of the server are) and for impact management (when an event occurs, what are the impacts). So if you MUST have that detail for config. understanding, and/or you have the level of monitoring that supports these CIs, then there is a valid case for their inclusion.

However my question is who will maintain this level of detail in a 'real' deployment of this conceptual model?? Do you have discovery tools that will 'drill in' to this level of detail (I know some do but not everyone has these available). Can you afford to scan the entire infrastructure environment for this detail, and then  integrate this back to Atrium?? That's alot of scan time and data and lot of integration/sync time and data, for anything other than a small departmental view. Without the assurance that either an automated process like an autodiscovery tool) or a manual process (like Change Management) is keeping this data up to date, is it practical to go this deep??

Hi Felix,

I do agree with careyw, the model you suggested looks good. The time you have spent for designing this model is worth.

Yes- Theoretically we can consider fan as CI but here we need to see from infrastructure point of view, if you have separate cooling system for machines then impact would be less(heat dissipation) if fan goes down or its stopped working. This will reduce number of r relationships. On other  point Memory and CPU is equally important for Impact relationship as it would affect on performance.(if CPU usage goes high -> directly affect on performance).

Thanks and Regards,

Abhijit Valvekar

I really liked your representation on a computer system ci. Very detailed. But as other suggested it takes lot of resoruces to maintain this level of detail. Otherwise it becomes stale very fast and will not serve the purpose of single source of truth.

I think you do not need to represent CPU and Memory as a physical ci unless you really want to track memory sticks and cpu sockets at physical level for example  when you want to interchange with other hardware. Even in that case who is going to update the cmdb relationships  when they interchange memory stick from one hardware to another hardware?

As per the events being generate on those CIs, the frequent events generated are when the CPU or memory reaches above a threashold, which can be mapped to application which is using that server instead of at physical  CPU or Memory level.