Can a service like maybe Messaging or WAN be considered as a CI for the CMDB ?
Also, what are the things that should be considred as a CI...

I have a thing here... If messaging is the Service and the Server names are the CI's.... The attributes to the CI will be the server name, IP address, etc...
And how do i link it to the other servcies like WAN ...

Am i going the right way ?

Awaiting your valuable inputs..
Thanx in advance..

Cheers
Winz_________________"Look at Frustration as a positive thing. It is the frustration that drives you to improve"

Can a service like maybe Messaging or WAN be considered as a CI for the CMDB ?
Also, what are the things that should be considred as a CI...

Determining scope and depth of a cmdb realy depends on the organisation it should serve. For organisations with heavy video/graphic usage such as a newspaper or a CAD/CAM dept, it might just be usefull to define internal video cards as separate CI's, whilst most organisations would find this very inefficient. Therefor it is almost impossible to answer your question, I'd rather advice you to adress this question within your organisation with all stakeholders involved (who pays for the maintenance of the cmdb? Who has the benefits?).

ITIL defines the infrastructure as software, hardware, documentation and service level agreements. Services as such are no part of it. It is smart however, to define you services in any table where you have the possibility to link them to CI's (most tools I know provide this). This will increase the value of your cmdb.

Regarding excel: yes of course it is possible to use this for starters. Realise however, that your possiblities will run out after a while, especially with documenting relations between CI's. However, it might be a good start, as your organisation still needs to decide on scope and depth of cmdb. If/when you have made up your mind, you will have a good baseline that you could import in most tools.

For clarification, I just wanted to bring up that using Excel spreadsheets for tracking this information is not really a CMDB so much as it is an Asset Register/Inventory. A real CMDB will maintain detailed dependency information such as relationship types and direction of relationships, audit histories, etc., which you will most likely not be managing in your Excel spreadsheets. It will also allow you to track far more than just your technical assets, as you would be able to track your vehicles, tables, chairs, offices, etc.

Also, from a generic standpoint, "anything" you want to track, which can have one or more dependencies to it and/or one or more dependencies from it, is a Configuration Item (CI). This includes anything at all that is important to the Configuration you are trying to manage. Examples include but are not limited to:

Starting with a simple asset list, although it will help your help desk and support staff a little bit, will be of little value and you may find it difficult to get buy-in for the next stage up.
I would have to recommend Access over Excel as this can provide information on the relationships between assets as well as their attributes. This will provide an immediate benefit when it comes to incident/problem/change management and makes your cmdb a little more extensible.
I would also recommend implementing from a top-down perspective, instead of trying to audit every single asset, whether it be important or not. Pick a few (2 or 3) key services provided by your system and populate the database with those. This is a quick way to prove the value of a cmdb and get buy-in from the upper echelons.

I must say: starting with Excel is puzzling me a little. For one, I think that the real value of the CMDB is in relationships and I don't see how Excel is going to help you do that effectively. BUT, starting the management of assets is a step forward and as long as you design your system in a way that you will be able to extract the information and place into another system later, then I would clearly start with what I have.

The problem is that you will have a hard time demonstrating value out of Configuration Management with such a system and I would therefore try to make sure you have a commitment from the organization to move to the next step before starting. The problem here is that you may find yourself with an outdated and unused Excel system and no willingness to go further otherwise. That is a waste of energy, money, and credibility.

While I generally agree with Michiel's reply, I must say that by any of my accounts, services are CIs in my book, for the simple reason that you will want to control changes you make to services, and the relationships you can build around services may be of enormous value. Example: I provide support services for Blackberry devices and I charge on a per call basis. If my service is in the CMDB, I will immediately know: (1) how many users I have for the service, (2) how many calls are related to the service, (3) How much to charge and to whom, (4) how many people do I need to train on the Service Desk, etc...

In another thread, we discussed incident classification and we highlighted what I consider a great category scheme using Service -> System -> Type. If you do this, you have matter-of-factly put your services in your CMDB._________________BR,
Fabien Papleux

To be frank... I have put down the papers in my current firm and moving out for a better opportunity.. So I am done with the knowledge transfer...
Also, got a news that the firm is looking for some readymade tool which might help them with this...

Sorry... could not be of any help on this one..

Cheers
winz_________________"Look at Frustration as a positive thing. It is the frustration that drives you to improve"

Looking for a ready made tool is a smart move. We're finding more and more that enterprises are going down some ugly roads that they can't easily get out of, with their home grown tools.

Building simple tools is not simple! For some reason, people jump through hoops to prove that they should be building their own solutions, themselves. What's worse is they rarely bring their executives into the conversation and truly show these executives their the implementation costs, the year-over-year maintenance costs, the options and the impact of each option. We still can't figure out why this is. I wonder if it has to do with IT staff wanting desperately to build their own tools to keep themselves interested in their day jobs or believing they're up for such a challenge?

In the entire ITIL list of disciplines, a CMDB is one of the more costly and complicated systems to design, build, deploy and manage. It rates right up their with things like implementing true Financial Management, Application Management, and a worthwhile DSL. Yet, for some reason, people want to believe that they can implement their own. It's almost like they intentionally hide the requirements of a worthwhile system so that they can justify doing it themselves. I'm stumped on this one...

Guerino1 (Senior Itiler),
I'll write some points from the System Administrators view.

There is a basic principle that rule every System Administrator - KISS
(Keep It Simple & Stupid).

I've been on such entry level ITIL course (green) - I liked it.
I've seen CA (implementation ~6months still not finished) - didn't like it.

The biggest problem is that most of the today systems are target to the managers (there are the money). Presentations are nice & promising, but the administrator has more work than before.
The most tragic of all is that mostly these products can do everything, but nothing really good out of the box.
As you said "What's worse is they rarely bring their executives into the conversation and truly show these executives their the implementation costs, the year-over-year maintenance costs, the options and the impact of each option."

ITIL is a reference, not an IKEA manual to build your bed.
Right tools for the right things is my answer to you!
Here I don't mean they should be self developed, open source or free, just the right ones.