Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Wed Sep 21, 2005 11:31 pm Post subject:
ITIL doesn't go into a lot of detail about CI types. And it only offers guidelines to what a CI record would look like.
ITIL is deliberately 'undercooked' when it comes to information architecture. It recognises that there will not be a one size fits all schema that is going to be suitable in every site.
It does suggest hardware, software and documentation as classes of CIs.
But I was just on another forum today where a post was asking where licenses fit into the suggested schema (and whether they would be CIs at all). There will be other kinds of active information that may require being brought under change control that don't quite fit into any of the above types.
So while you could certainly include these suggested categories in a schema, you will probably have to develop one of your own.
The information requirements of ITIL processes is one area where ITSM software systems add value. Obviously they come with pre-built data dictionaries, and the better (and more expensive ones) cover 99% of the information requirements of mature processes. Though the value lists of specific attributes are often owner configurable. So you might find a type field on a prebuilt CI record in a given system, but you would have to configure the values it can take.
Bear in mind though that classifying your CIs is only the start. To get mature process integration, your CMDB should support an end-to-end view of your services. It should show how 'resources' become delivered 'capabilities'.
Accurately capturing the relationships between CIs is more important than 'classifying' them. And one of the most important relationships to capture accurately is 'aggregation'. Collections of components that together consitute a system, and collections of systems which constitute a service. (All of which are CIs) These aggregate levels are sometimes referred to as the physical, logical, and service layers of the infrastructure. (Keep in mind that 'physical' has the broardest possible definition here.) Also remember that a CMDB will never be a 'tree'. It will be loaded with many-to-many relatioships. One component might belong to several systems, and one system to several services.
Also it is worth noting that classifications for the physical / component layer would be unusable at the service level.
Services might be classified technical and professional - indicating the mode of production, and sub-classified as core, subscription and discretionary - indicating the mode of access/consumption.
One of the key drivers behind service classification is the requirement to apply the correct costing or charging models - while representing the aggreagations from things to services in three different layers of 'abstraction' allows you to document and manage a true end-to-end service model.
The goal is not simply to record and manage your CIs, but rather to capture and manage the configuration that turns CIs into services.
Agree completely with the post above from RJP. I would also add that defining how 'deep" you go into defining your CI's will have a direct impact on your future workload as it relates to maintenance of your CMDB.
As an example: in a server you can define a lare number of items, e.g. -- hdd, memory, HBA's, network cards, etc. If you make each component a CI then when you do some sort of change you will need to ensure your CMDB is updated down to the very granular level.
However, if you define the lowest level of CI to be 'server' and define it as "P615' (IBM server type), then any changes would be ket at this higher level.
Hopefully, this makes sense. break your CI's down to the level that you feel your organization will be comnfortable maintaining and to the level that you will need to track the information and where you will gain some value..
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum