Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: L86D
New Today: 13
New Yesterday: 72
Overall: 139703

People Online:
Visitors: 67
Members: 3
Total: 70 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - CMDB Data
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CMDB Data
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management
View previous topic :: View next topic  
Author Message
Camelia
Newbie
Newbie


Joined: Sep 28, 2006
Posts: 19
Location: West London, UK

PostPosted: Thu Mar 15, 2007 9:47 pm    Post subject: CMDB Data Reply with quote

As a first stage to gathering our CMDB data we currnetly have an external company in going round all our sites labelling all our Cabinets to a naming standard that has been agreed; once they have all the raw data (location named cabinet list) what is the best way to have them deliver this to me for future use once I have the CMDB in place? Possible ideas are excel or access database - what are the pros and cons ie what should I be thinking about as I do not have a CMDB tool in place yet?

Cheers,

Camelia.
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Thu Mar 15, 2007 10:44 pm    Post subject: Reply with quote

Hello Camelia,

There are many answers to this...

- CSV
- Excel
- XML
- other text file formats
- Etc.

The question becomes what's the easiest way for you to load your CMDB. If you want to do it manually, simply have the consulting company put the information in your CMDB, directly, or hire low cost labor to enter it manually (you can hire foreign companies to do this effectively).

If you want to automate the upload, then simply have them give you a format you can work with. Usually, if they collect the information and put it in Excel, they're putting it in a two dimensional format that should be easy to work with and can be saved as a CSV file for upload.

Since our CMDB is web based, companies that collect manual information, such as the cabinet information you're collecting, typically have the collectors walk around with wireless laptops and enter the data directly into the web based forms. This ensures that the work is done "once" and all data doesn't have to be merged, as it instantly all goes into the same repository. They can later export the data, from the CMDB, to whatever format they need in a few clicks. Another advantage of doing this is that relationships between the collected data and other information in the CMDB can be instantly created, making the data that's entered useful, almost immediately.

I hope this helps.

My Best,

Frank
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3292
Location: London, UK

PostPosted: Mon Mar 19, 2007 2:42 am    Post subject: Reply with quote

Despite Frank's subtle sales pitch in his post, he is correct about the different type of data format etc that the CMDB data can be put in as well as methods of recording

However, you have to first decide what data you want to track, why, and how are you going to manage it - from a configuration management standpoint. Get the data, verify the data, audit the date

The company I had worked for used both internal Data cetner staff and external vendor staff to gather the information that though to be required

Now, each group had an excel spreadsheet which they updated from a sheet of paper..

I had the unappreciated joy of trying to normalizing the data.

First, there were no standards defined as what to put down for manufacture, model, device type etc as well as any data limits set on certain kind of data

For example

I had Servrs, svrs, serveres, serviers, etc for the device type - Server. If they had to choose from a drop down etc, the data would have been easier to glean and clean

For model types I had
Sun e250 Unix Server, Sun e250, e250, sun unix etc

where the manaufacture should have been Sun and the Model should have been e250 and the device type server

I am sure you see what I mean

Then there is the issue of identifing the device

Do you 'label' all your devices with a corporate unique identity or a data center centric one. When do you do this ? Does your h/ware maintenance contracts use their own etc...

So the Sun e250 Server would have a company ID (unique), a serial number (chassis) a location - building, floor, room, cage/rack, section, U number, power supplies, etc

And that is just the physical data - what about the fungible data such as IP, O/S, version, applications (versions), LAN, etc

you see the issues.

The other big problem is the unreadability of some S/numbers on hardware.

Some vendors put them on the side or on the bottom and if you did not record them when you first received the device or lost the records... then you may have to 'pull the device out' to check the details....

While I ding Frank about him selling his products as part of answers in this forum, I also know he is trying to make a point for the person making the question.... There is alway some solution which some one else has made because they saw the issue before. And some solutions become a product that is sold to people.

His suggestion about using wireless devices also depends on the type of security management concerns are in place at the location.

You just need to find not the best solution but the best available the 80/20 rule as always
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
alphasong
Itiler


Joined: Mar 03, 2007
Posts: 33
Location: Minneapolis

PostPosted: Mon Mar 19, 2007 2:58 am    Post subject: The data modeler is your friend Reply with quote

You should waste no time in involving a data modeling professional. CMDB data presents some of the most difficult challenges in data normalization and is not for amateurs. People can spend their entire careers in data architecture.

See www . dama . org (the Data Management Association), Rob Seiner's TDAN . com, the dm-discuss group on Yahoo.com, and my own weblog www . erp4it . com for an introduction to data architecture principles. I have written extensively on reference data architectures for the CMDB as well as the IT value chain considered as a whole.

Charlie
_________________
Charles T. Betz
Back to top
View user's profile Send e-mail
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3292
Location: London, UK

PostPosted: Mon Mar 19, 2007 5:18 am    Post subject: Reply with quote

Charles

I agree with what you are trying to about data modelling but if you are going to gather data for a CMDB you need to have an idea of what you want to manage - even if you dont know how to arrange it in a database just the information you need

I want to keep track of the .... for the equipment....

thanks for the references
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
alphasong
Itiler


Joined: Mar 03, 2007
Posts: 33
Location: Minneapolis

PostPosted: Mon Mar 19, 2007 9:27 am    Post subject: That's exactly what a data modeler *does* Reply with quote

Hi John,

That is the first thing a data analyst does -- gather stakeholder requirements at a conceptual level, by talking to people such as yourself and keying in on the nouns they use to describe their business. The fact that in this case the "business" is IT makes things no different: the data analyst homes in on the use of terms like:

Server
Software
Asset
Software
Application
Release
Configuration Item

and so forth.

A database-independent conceptual data model is then created, with candidate entities, attributes, and their relationships, e.g.:

A Server may be an Asset.
A Server may have Installed Software
Installed Software may have a Version
A Release may consist of Configuration Items

and so forth.

Notice that this is all about business semantics - not about RDBMS tables and columns versus Java classes and properties versus XML elements and attributes versus Cobol copybooks versus ... you get the picture.

The conceptual model is then elaborated into a logical model and then into a physical model suitable for deployment.

The trouble we have in ITSM is that many people seem to think that data modeling is only about the physical level. That's the least of our worries. The big problems come in getting the business semantics correct, and there are significant disconnects in the industry today over what we are calling things.

Just try to reconcile the various uses of the terms "Release" or "Service" for example. I've taken a whack at it in my book, but there is still great ambiguity in the industry.

Regards,

Charlie
_________________
Charles T. Betz
Back to top
View user's profile Send e-mail
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Mon Mar 19, 2007 2:36 pm    Post subject: Reply with quote

Gentlemen, please correct me if I'm wrong, but it appears from Camelia's post that she already knows what she wants. I believe her question was about the best way to transfer/convey the information from the 3rd party collecting it to her own organization, after collection. Is this not the case?

Camelia,

My simple recommendation is that you not reinvent the wheel. There are multiple vendors that already offer prepackaged, cost effective CMDBs that come with many features which you will need in order to properly utilize one (predefined data model, uploaders, downloaders, searching & data mining solutions, reporting solutions, social networks, mind maps, etc.). You will be able to get far more for far less than it will take to implement it and maintain it all, yourself. I highly recommend you explore as many prepackaged solutions as you can and their viability for use within your enterprise, before making any decisions about a CMDB. Understanding what a real one can do is critical before you undertake the implementation of one. The best way to do this is to look at as many as you possibly can.

Once you have chosen a CMDB, upload/download solutions will be part of the solution and will help dictate what you can or can't do to get data in to or out of your system. However, no matter what, you will almost definitively have to do some form of transformation between the source system and its data representation and the target system and its data representation. There are a number of options to implement such transformations, such as using simple perl scripts to more elaborate solutions, such as ETL tools.

However, until you do choose a CMDB, you are probably well suited to simply collect all your data in spreadsheet form, since the collectors of the information are probably keeping their inventories in spreadsheets. You can always use those spreadsheets to help facilitate linear uploads of the data, long after the collectors are gone.

Anyhow, I hope this helps.

My Best,

Frank
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
alphasong
Itiler


Joined: Mar 03, 2007
Posts: 33
Location: Minneapolis

PostPosted: Tue Mar 20, 2007 9:01 am    Post subject: Model the data before you talk to any vendors Reply with quote

Camelia,

An Access database will be superior to Excel spreadsheets, due to normalization and data integrity issues. That will lead you into the data modeling conversation, which doesn't necessarily mean re-inventing any wheels. It will lead you to a greater understanding of your own requirements, which is advisable before you reach out to any vendors.

-Charlie
_________________
Charles T. Betz
Back to top
View user's profile Send e-mail
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Tue Mar 20, 2007 10:56 am    Post subject: Reply with quote

Camelia,

I forgot to add that you should run all options by your IT leaders before making any decisions. They might have a better view of the organization's tactical vs. strategic needs. They may feel that creating and managing a small data model in Access may be worth your while or they may feel that it's a complete waste of valuable time, money, and energy. Ultimately, get feedback from critical stakeholders by giving them clear options, before you make any decisions.

However, if all the vendor is doing is collecting cabinet based information, I wouldn't personally go down the road of a full CMDB, yet, as you will need to truly understand what you want out of a CMDB before you implement it. When it comes to a CMDB, you should have a picture of your Configuration Management plans before you try to implement a tool. There will be processes you will need to understand and put in place to manage your configurations and I highly recommend that your enterprise take the necessary time to understand them before implementing such a tool in any technology.

It's important to remember that a CMDB, whether you build your own or buy one, is another application/system in your environment that will require regular support and upgrades. It will require dedicated labor and possibly even infrastructure as it grows. As a result, it means that you will be draining time, money, and energy to maintain something that most likely has nothing to do with your enteprise's core business. This means you'd be adding a new expense to your enterprise. Therefore, I would not recommend diving into designing/building or purchasing one until you know exactly what you can or can't invest in such a system and exactly what you intend to get, in return, for that investment.

Again, run it by the people that are accountable for things like decisions for how the organization needs to operate and budgets. These people usually have responsibility for the bigger picture and can be a big help if you leverage them properly.

I hope you find this information useful.

My Best,

Frank
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Cekir
Itiler


Joined: Jan 12, 2007
Posts: 48
Location: Warsaw, Poland

PostPosted: Tue Mar 20, 2007 8:56 pm    Post subject: Reply with quote

Camelia,
you need 2 types of information about IT Assets that go into CMDB:
1) Assets themselves with their attributes,
2) relationships between them.

No matter what kind of tool you will choose, you will probably need the relation tables as a result. Therefore choose a tool that will be able to export data to the common text tables format like CSV, so that it would be easily importable into the relation database.

As the Assets themselves have easily definable attributes, you will not have much problems with defining raw format for them. You will however probably need different table for every type of assets.

Relationships make some more problems. My advise is to make the external company to create as many relationships types as they find (connected to, installed on, standing near etc.) and add them in the table like
AssetID1, AssetID2, RelationshipTypeID
When you decide how your CMDB architecture look like, you will be able to map the received relationship types into your CMDB relationships. You will probably not use some of relationships like "standing near", but you don't know it yet since you don't know your CMDB architecture.

Anyway - before deciding to hire external company to label Assets you should check the best practices for asset management. You can go to IAITAM org site to get some info and training about them. You will find out that there may be some other solutions like using good auto discovery tools or choosing different type of labeling.
_________________
Krzysztof (Chris) Baczkiewicz
IT Standards Support
Eracent
Back to top
View user's profile Send e-mail Visit poster's website
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Sat Mar 24, 2007 3:39 pm    Post subject: Reply with quote

Hello Cekir,

Cekir wrote:
1) Assets themselves with their attributes,
2) relationships between them.


Yes, exactly. Many people refer to #1 as "containment relationships" and #2 as "association relationships". Object-Oriented Analsys and Design paradigms will refer to them as "Has-A" vs. "Uses" relationships (not to be confused with "Is-A" which represents inheritence).

My Best,

Frank
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Cekir
Itiler


Joined: Jan 12, 2007
Posts: 48
Location: Warsaw, Poland

PostPosted: Mon Mar 26, 2007 8:22 pm    Post subject: Reply with quote

Yes, and no Smile

In theory, every attribute is an entity that is a part of other entity. There is however a huge difference between color and processor when they both describe a machine.

Therefore in practice I would suggest to differentiate between attributes (color, serial number, speed, etc) and parts (software installed on, graphic cards, processors, drives).

Also from asset management point of view we can say there is a difference between color and a processor. We cannot explicitly talk about a color that is an item. We can say that 2 computers are red (hmm.. has anyone seen a red desktop computer?) but we then say about type of color, not the specific item.
When we talk about processors as a part of a computer, we can say that 2 computers have the same type of processor, but we can also say that they (processors) are different items. Of course we may not need to instantiate processors and treat them as just attributes of a machine. The difference however is, that we cannot instantiate a color.

Frank,
Do you think it is good to unify the relationships at this stage?
I think it is better to gather all kind of relationships noticed while collecting information and unify them after we decide on the granularity we need. I mean that sometimes we don't care that the software installed on the machine have the same (has a) relationship with the machine as the hard drive.
_________________
Krzysztof (Chris) Baczkiewicz
IT Standards Support
Eracent
Back to top
View user's profile Send e-mail Visit poster's website
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Wed Mar 28, 2007 5:49 am    Post subject: Reply with quote

Hello Christopher,

Cekir wrote:
Frank,
Do you think it is good to unify the relationships at this stage?
I think it is better to gather all kind of relationships noticed while collecting information and unify them after we decide on the granularity we need. I mean that sometimes we don't care that the software installed on the machine have the same (has a) relationship with the machine as the hard drive.


The kind of data you store in your CMDB will dictate what data (such as relationships) you care about. Most enterprises make the mistake of building a CMDB which scours assets for the physical components that make them up and, as a result, will collect oceans of data that add little value to an enterprise. Others tend to start at the business service level and then drill down, one layer at a time, to understand how services, systems, people, organizations, etc. are all tied together. These types of relationships usually seem to add far more value to businesses and executives.

The reality is that you shouldn't have to collect/define relationships in a good CMDB. The CMDB should create and label them for you. If you're doing this, yourself, you might want to question the flexibility and power of your solution. After all, in this day and age, the relationships you're using shouldn't be any different than the relationships every other enterprise out there is using. So, they should all be coming pre-defined and ready to use. In reality, you shouldn't even have to "create" the relationships between entities. A good CMDB will implicitly capture most relevant relationships for you and tag them appropriately, as they're created.

Anyhow, I hope this helps.

My Best,

Frank
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Cekir
Itiler


Joined: Jan 12, 2007
Posts: 48
Location: Warsaw, Poland

PostPosted: Wed Mar 28, 2007 8:52 pm    Post subject: Reply with quote

Guerino1 wrote:

The reality is that you shouldn't have to collect/define relationships in a good CMDB. The CMDB should create and label them for you. If you're doing this, yourself, you might want to question the flexibility and power of your solution. After all, in this day and age, the relationships you're using shouldn't be any different than the relationships every other enterprise out there is using. So, they should all be coming pre-defined and ready to use. In reality, you shouldn't even have to "create" the relationships between entities. A good CMDB will implicitly capture most relevant relationships for you and tag them appropriately, as they're created.


If I understand you properly, you are saying that the configuration manager should use the relationships provided by a tool.
Well, it will definitely save time and money to use already defined CMDB. It looks you have a CMDB model that is self updating and reusable for ALL your customers. Hmm... of course it will not work for situations where the service needs different model, but you can always change the service to be compatible with the tool.

This way has it's advantages. Seriously. I guess your CMDB model is based on good research and the tool deployment is also some kind of consultancy. I believe you are also opened for customizations. I am however full of doubts watching a tool driven management.

How do you deal with not standard relationships. Or maybe your model covers all possible relationships?
_________________
Krzysztof (Chris) Baczkiewicz
IT Standards Support
Eracent
Back to top
View user's profile Send e-mail Visit poster's website
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Mon Apr 02, 2007 1:41 am    Post subject: Reply with quote

Hello Christopher,


Cekir wrote:
Guerino1 wrote:

The reality is that you shouldn't have to collect/define relationships in a good CMDB. The CMDB should create and label them for you. If you're doing this, yourself, you might want to question the flexibility and power of your solution. After all, in this day and age, the relationships you're using shouldn't be any different than the relationships every other enterprise out there is using. So, they should all be coming pre-defined and ready to use. In reality, you shouldn't even have to "create" the relationships between entities. A good CMDB will implicitly capture most relevant relationships for you and tag them appropriately, as they're created.


If I understand you properly, you are saying that the configuration manager should use the relationships provided by a tool.
Well, it will definitely save time and money to use already defined CMDB. It looks you have a CMDB model that is self updating and reusable for ALL your customers. Hmm... of course it will not work for situations where the service needs different model, but you can always change the service to be compatible with the tool.


Yes, the enterprise (not just the Configuration Manager) should use the relationships that already come with a good CMDB. If you're defining your own relationships, you're re-inventing the wheel. In this day and age, there are no relationships that you will need that are different from relationships that any other enterprise will need. If the tool does not come with a library of existing relationships, I would question it's value to the enterprise.

We do have a CMDB model that is self updating, in that it knows how to automatically capture and maintain "implicit" relationships. It knows how to delete and archive old relationships and replace them with new, more relevant ones. It also allows "explicit" capture of relationships. So, for example, you can go in and tie Business X to 500 specific Assets as an Asset-Specific-Business-End-User of those Assets.

Also, to address your statement about Service to Tool fit... we have yet to run into a single Service model that doesn't fit cleanly into such a philosophy, so there has yet to be a case where the Service has to be modified to be compatible with the tool.

Quote:
This way has it's advantages. Seriously. I guess your CMDB model is based on good research and the tool deployment is also some kind of consultancy. I believe you are also opened for customizations. I am however full of doubts watching a tool driven management.


Yes, our CMDB was built based upon:

1) The requirements, best practices, and recommendations specified by ITIL.
2) The needs of all of IT, not just the factions covered by ITIL.
3) The needs of all business stakeholders, not just IT (because a good CMDB solves needs for more than just IT).
4) Solving the need for higher order Knowledge Management in an enterprise and its IT organization.
5) Understanding how the brain works, so that data and information can naturally, efficiently, and effectively be collected, stored, indexed, accessed, transformed, rendered, disseminated, etc. in the most powerful ways available.
6) Web 2.0 requirements, to drive modern global compliance and ease of use.

NOTE: Number 5 is ultimately the most important to us.

Quote:
How do you deal with not standard relationships. Or maybe your model covers all possible relationships?


In the case where someone comes to us and shows us a new relationship that we've missed, we immediately deploy that relationship to the platform. Because our solution is a hosted SaaS model, the modification instantly gets pushed out to all of our clients and they all benefit from the new relationship.

However, we also let enterprises create customizations within the relationships that can already be created in the system. So, for example, there are generic relationships that can be categorized to be very specific relationships. Users can also put notes, right in the relationships. They can also do things like set the severity of the relationships, see audit details about relationships (such as who created them, who modified them, when, where, how, why, etc.).

But, keep in mind, that our philosophy is that the most powerful and effective solution is one that's ready to use. Our system comes pre-populated with thousands of relationships that can be used. We also have a very large and comprehensive list of entities that can be tied to each other (http<://>www<.>traverseit<.>com</>it_ops.html).

I think that what makes us stand out as different and what gives us a great deal of pride in what we're doing is that we're not trying to build a CMDB. We're trying to build a brain. A CMDB is a small subset of what the brain is. Therefore, if you build a good brain, you automatically get a good CMDB, since it's a symptomatic fallout of what a good brain will do. If you or anyone is ever interested in understand this and the differences between the two, please always feel free to contact me and I'll do my best to accommodate.

Anyhow, I hope this helps.

My Very Best,

Frank
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.