Posted: Mon Dec 18, 2006 7:41 pm Post subject: Building a CMDB, need help in CI structure
I am building a CMDB those days, and I need your assisstance in determining the CI structure.
I appreciate if you may send me a CI structure, includes:
* A list of CI types you choose in your organization
* For each CI type: what was the main attributes?
And, if you have deeper experience with CMDB, I have few more questions"
* Do you have CI categories, else then CI types?
* The CI structure: how many levels of CIs you choose, What were those levels?
* A list of optional CI statuses.
* A list of CI relationship types.
Thank you for your answer.
I know there are tons of information about CMDB, I must admit - that's a problem. I got lost.
But still, you may assist me: I am looking for very particular list:
A list of CI types from a real organization. A list of CI that passed the "Fire test" of being in production. No a theoretical but practical list of CI types, with it's attributes.
So, if you have such a list (or a link) - I appreciate if you may forward it to me!
I would definately agree with Frank in that you can find some articles and various white papers that will give you an idea of a suggested structure. But it really depends on your organization and what value you want to gain from the cmdb when looking at the attributes. In our organization i believe we are up to 125k CI's. For our structure or hierarchy at the highest level we divided from hardware, software, environment, documentation and a few more. From there the next level down example on hardware goes to Platforms (Desktops, Servers - corporate and non corporate), mainframe etc. On the application side we are still at a very highlevel listing hte individual apps but not all the components that make up that app at this time (such as open system interfaces etc). Same with mainframe. For example our mainframe HR application consists of several thousand indvidual programs, JCL's etc. It was not of value at our level of maturity to go to that individual item level but by design as we mature we have positioned ourselves to be able to add that next level.
Far as attributes it just depends on what you want to track within your organization which will bring value to you. One thing that can bring great pain to your cmdb implementation is too much information, it can make it unmanagable. For us, granted we are not very developed yet with our implementation so some attributes that we are tracking for example are - software version, hard drive size, cpu size and count, rack location, maintenance windows, OS version, service pack level just to name a few.
I'll dig around see if i can find an article which can speak a bit more specifically to what you are looking for.
Relationships The relationship of the CI with all CIs other than 'parent' and 'child' (e.g. this CI 'uses' another CI, this CI 'is connected to' another CI, this CI is 'resident on' another CI, this CI 'can access' another CI).
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Wed Dec 20, 2006 12:15 pm Post subject:
Hence why ITIL is so limited.
What you're looking at is a very limited and inadequate set of attributes that also pigeon-holes your CIs into really being nothing more than general assets (hard computing, hard non-computing, and soft/virtual (e.g. SW).
It also recommends that you mix attributes with relationships, which will definitely get people into some serious trouble. For example, one asset may have many associated changes or, vice versa, one change may have many assets. It won't be pretty if you follow their recommendation.
And, finally, it doesn't tell you how to implement all of this, properly. Put this attribute specification into any database and try to first load it and then keep the information in it, up to date/current, over time, for a growing enterprise, and see how much time, energy, and money you waste on it.
Sorry, but it makes me cringe when I see things like this, because the poor inexperienced person thats seeking to implement a solution will read the above and say "Gee, I can do that!" and not have a clue as to what either the short and/or long term impacts will be.
Here's your first problem, from experience... Your model, especially if you follow the recommendation listed above, will be highly limited and won't let you scale to track and manage all the real information you'll need to truly make your CMDB effective.
Here's your second problem, from experience... The UI you use (or don't use), over the model, will be the first thing that will cripple the effectiveness of the system, making it difficult for people to interact with the system to create, edit, search for, extract, and format information.
These are only two of many you wil have. I wish anyone who undertakes such an initiative the best of luck, as they will need it.
Anyhow, I hope this helps.
Frank _________________ [Edited by Admin to remove link]
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