CMDB experts

[Steelmaker]

We have recently purchased the Assyst system from Axios. We have implemented the incident system and am now starting to plan for CMDB and Change implementations.

There has been some disagreement on the development side(all in house development) as to how to handle it in the cmdb.

For example(high level):

We have an Order entry system and this Order entry is comprised of 5 programs(pricing program, acknowledgement program,entry program, shipping info program,product code program):

Option 1:
Some people think we should have a ci named order entry. If we need to change something in the order entry system, then open an RFC referencing order entry system.

Option 2:
Some people think we should have several cis, a ci for every program in the order entry system with a version # associated with it. If we need to change the pricing program and entry program, then open an RFC referencing 2 cis(pricing program and entry program).

What do existing ITIL shops typically do for development?

Also, how many configuration items do some of you hold in your cmdb?

[UrgentJensen]

Hi Steelmaker,

I don't want to tell you what you already know but i'll add some context for anyone who might be new to the topic...

One of the principles of ITIL is that you use it where it will add benefit of your unique organisation. To apply that at a cmdb level would be to suppose that you only manage the CI's that matter to you. So you won't find a 'standard' for the volume of CI's or their attributes.

Having said that, in regard to your initial question I'd suggest that you could, if you all felt appropriate, have a CI for each individual application AND a CI for the overall 'service', i.e. 'Order Entry System'.

[Appropriate might depend on how well known those five apps are as 'Order Entry System' in the organisation and if it has any correlation to performans/SLAs etc.]

Initially that might sound like duplication, but it doesn't have to be.

One of the main benefits of a cmdb is to allow you to view and understand the relationships between CIs. And there is a clear relationship between the Order Entry System 'service' as a whole and the individual applications and from an IT standpoint you need to know that. The customer may only know it as the Order Entry system but IT need to know more about it than that.

Afterall, if you change CI 'Order Entry App 3', it will have a tangible impact on CI 'Order Entry System'

So what info do you keep in the Order Entry CI? Well, you can simply maintain attributes describing the relationships with the individual application CIs but don't copy in all their unique attribute in too, that would certainly be pointless duplication.

I hope that helps a little,

UJ
_________________
Did I just say that out loud?

(Beige badge)

[cjmt]

One way to create a global plan for your CIs would be to analyse your current inventory and define what could be thought as standard "profiles". This way, you can also get a feel of the granularity level that your particular system needs.

[Cotswolddave]

Hi,

It depends on your need for control and communication. You could just have the one CI for order entry and reference all changes against it. It means it is difficult to spot which elements of order entry are likely to affected so you would have to read the text in the change documents.

If you have multiple CIs for each element it then makes it easier to indicate what you're changing and to log incidents at a more granular level for root cause reporting. But you have to maintain and communicate more CIs and their definitions.

The ITIL guidelines have asset control, product life cycle, service mapping all referenced as to what a CMDB could do. In practice you can mange assets without a CMDB. You can manage development using specific SW product toolsets - serena, subversion etc. But you can't really manage services without using a CMDB in a service desk as it provides the common naming and understanding between CIs for different processes. So you may be right in that you don't really have the best repository for your development teams - unless someone can show you how Assyst makes it easy!

Dave