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: VV40
New Today: 36
New Yesterday: 71
Overall: 146136

People Online:
Visitors: 64
Members: 1
Total: 65 .

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 - ITIL Recommendations for CMDB database
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

ITIL Recommendations for CMDB database

 
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management
View previous topic :: View next topic  
Author Message
thirumaran
Newbie
Newbie


Joined: Mar 21, 2006
Posts: 7

PostPosted: Wed Mar 22, 2006 12:43 am    Post subject: ITIL Recommendations for CMDB database Reply with quote

Hi All,

Is there any ITIL Recommendations or checklist that needs to be followed during modelling a CMDB database .

thanks in adv
thirumaran
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Wed Mar 22, 2006 9:47 am    Post subject: Reply with quote

Good Day Thirumaran,

There is no specification that I know of. ITIL does, at a high level, speak of many things like Incidents, Problems, Assets, Documents, etc. being in your CMDB.

However, if you're about to undertake such an initiative by yourself, I would recommend you're careful about how much you get yourself into. My firm spent many resources for many years getting to a point where we have everything in one CMDB. We learned the hard way that it's not that easy to achieve without a great deal of support from your upper management and a significant amount of expertise in areas such as data modeling, data mining, higher order information visualization, highly distributed application development, and engineering, not to mention being very fluent in a great deal of the latest technologies that can be used to achieve all of these. Luckily, the end result of our efforts is a commercial platform that we can go to market with.

The traditional ITIL implementation strategy is to either build or buy a solution for a single vertical, such as Incident Management, roll that out, and then realize that after all that time and all that money you will then have to start on another vertical, such as Problem Management. Doing this will create a very deep hole in your company's wallet, not to mention put your full ITIL implementation many years out. After all of that, a mature organization will start to realize that it has a very big problem... it can't share data across all those vertical tools. This is where you're CMDB will come in. A good CMDB is even harder than any of the vertical process areas, as it is really a horizontal, across all of them. One that is decoupled from the verticals will have a hard time conforming to the protocols, data models, and technologies that each vertical was implemented with.

Anyhow, I hope this helps answer your question.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
thirumaran
Newbie
Newbie


Joined: Mar 21, 2006
Posts: 7

PostPosted: Wed Mar 22, 2006 9:02 pm    Post subject: Reply with quote

Dear Mr.Frank Guerino

As mentioned by you "significant amount of expertise in areas such as data modeling" , i understand this .

When we talk about CMDB modelling CI's play a vital role. I require your advice on this.

1) as per ITIL-CMDB a CI can contain /relate to other CI of it's same type.
(i.e) a CI of one type canoot be related to CI of another type (is it true)

2) what approach do you recommend for a Asset Management CMDB data model.
a) Put all the CI's in a single entity.
b) Create a seperate CI's for each CI class.
It will be much helpfull for me if you can through few points on the pro's & con's of #a & #b.

Thanks in advance
G.thirumaran
Hyderabad
India.
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Thu Mar 23, 2006 1:27 pm    Post subject: Reply with quote

Hello Thirumaran,

Please see my response, embedded, below...

thirumaran wrote:
1) as per ITIL-CMDB a CI can contain /relate to other CI of it's same type.
(i.e) a CI of one type canoot be related to CI of another type (is it true)


A CI can be related to any other CI. A CI can, in rare occasions, also depend on itself if there is a role/relationship dependency, upon itself. Many people will refer to this as a circular dependency.

thirumaran wrote:
2) what approach do you recommend for a Asset Management CMDB data model.
a) Put all the CI's in a single entity.
b) Create a seperate CI's for each CI class.
It will be much helpfull for me if you can through few points on the pro's & con's of #a & #b.


This is not an easy question to answer. It will depend on what you are trying to achieve. My recommendation is that you are very careful about the decision to build your own CMDB. Taking on this project will be a much larger effort than you think. As a result, like many companies out there, you will start it but you will never be done with it unless your company is willing to spend a very significant amount of time and resources on it. If they are, then I would recommend buying one, as it will be a faster rollout, you'll get more for your money, and the vendor will be in the business of constantly improving it.

I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
thirumaran
Newbie
Newbie


Joined: Mar 21, 2006
Posts: 7

PostPosted: Fri Mar 24, 2006 3:53 am    Post subject: Reply with quote

Hi ,

Today i read an very interesting artice on ITIL - CMDB.
The extract is below .

1) "“Although a 'child' CI should be 'owned' by one 'parent' CI, it can be 'used by' any number of other CIs…"

what does the above statement implies ?
How will the table table structure look when we are supposed to capture the CI's relationship

thanks
Thirumaran
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Fri Mar 24, 2006 5:32 am    Post subject: Reply with quote

thirumaran wrote:
1) "“Although a 'child' CI should be 'owned' by one 'parent' CI, it can be 'used by' any number of other CIs…"

what does the above statement implies ?
How will the table table structure look when we are supposed to capture the CI's relationship


Hello Thirumaran,

I will try to answer the questions with a software example...

You can have a piece of software that is used to build a very specific product "X". In addition to building "X", this piece of software can be used to build another product called "Y". It would be part of "X" but "Y" would also depend on it.

The table structure question is a bit vague, as there are multiple different impementations of how to model your answer. You layout/structure will be however you choose to design it. No answer is right or wrong.

I hope this helps.

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


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Fri Mar 24, 2006 9:24 am    Post subject: Reply with quote

I'd like to start by seconding all Frank has said. CMDB's provide 'horizontal' functionality and provide a critical repository for data required to control many other processes.

A couple of other points. Database design methodology (what kind of relationships etc) is actually secondary issue. CMDBs, despite the acronym are not usually databases - per se. (As I think Frank hinted at). The point of the 'federated' metaphor is that CMDBs draw very much on the idea of data wharehousing - multiple data sources (only some of which are relational databases) must be cordinated and 'mined' in a effective manner.

You would however expect to use a 'master' relational database to act as a control and coordination point for all your configuration information.

Before you decide on CI attributes and relationships - you need to establish, your scope, and your meta-data framework. The information in the CMDB, should have a strictly controlled scope that supports the required management functions, and goes no further.

You should also recognise that infrastructure information 'becomes' different 'things' depending on the objectives, roles, actions, etc, of those using it. This is your 'ontology' and there will not be simply one CDMB ontology required. By this I mean your CMDB should not simply represent 'components' and their relationships in various aggregations of dependency and resource provision. It should also be able to represent and present those elements and collections as different 'things' according to discrete management requirements.

So for the sake of change control, you need to be able to do delta audits at the component level: a CI record that represents a component and can be aduited against its current state is importent. The component ontology will be important for good problem management as well - primarily in ensuring meaningful record keeping within the error control cycle.

But for the sake of change and release management you will very much need to represent the configuration as 'systems' which are in many cases abitrary groupings of many different kinds of CIs around function, technical expertise, management responsibility etc. But becasue of this these operational 'facts' such abitrary groupings of CIs need to be recognised and supported.

You also need to represent your configuration as services. Ideally you should be able to examine a CI and see how it contributes to a functional capability provided to the business.

This 'polymorphous ontology' is implemented via the meta-data schema of your CMDB as has little to do with the 'real' attributes of CIs.

Primarily though remember that the CMDB is a 'management' database - not a technical one. There are any number of tools for technology managment, which will support mapping of technical dependencies, root cause analysis, real time capacaity and availability monitoring and reporting, and tec.

In my opinion - the most important objective for the CMDB is:

It should enable the IT organisation to represent and manage it's resources as production factors in the end-to-end delivery of services.

Every process in ITIL is on one hand dealing with the infrastructure, and on the other dealing with services. The CMDB, ultimately, is where you need to define how the infrastructure becomes services. If you do this you take a huge load of all the other processes, and that's where the real underlying value of the CMDB is. Until you do that, you are still in the 'asset register on steroids' metaphor and your CMDB is going to be a technology management inprovement measure. It should be a service management improvement measure.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
twohills
Newbie
Newbie


Joined: May 28, 2006
Posts: 6

PostPosted: Thu Jun 01, 2006 4:41 pm    Post subject: Reply with quote

Hi RJP

I'm always intrigued by how hard CMDB is. To my knowledge, after 20 years of ITIL nobody has yet come up with a standard schema, or even a clear methodology for designing a schema. (Finally some of the vendors are on to this just recently). it seems to me 80% of CMDBs should be absoluteluy identical from company to company, and that 80% should be good enough to get an organisation started, even if they grow uniquely from there.

I really feel for people coming to terms with a CMDB. I think we in the ITIL community have done a crappy job of making CMDB accessible and achievable. Not having a go at you personally, but what is a Change Manager in an average firm to make of "polymorphous ontology"? What I mean is that every bit of advice I have seen about CMDB speaks in generalities and concepts. I've not seen much concrete practical advice on how to go about cutting a schema, or what piece of software to put it in and how to do that. In my experience, most CMDBs are defined by an advanced methodology called "whatever the service desk vendor says it is".

When we see surveys of the uptake of the various functions of ITIL, CMDB is almost always the lowest. it is easy to understand why. it's too hard
_________________
Rob England, Two Hills Ltd
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Thu Jun 01, 2006 11:06 pm    Post subject: Reply with quote

Twohills,

yep it's hard, it's a common 'ITIL deal breaker' and the future of vendor supplied solutions is mega$$$.

I have however spent two years putting in hard yards on this challenge. Behind simple methods that break through and work are often some thorny 'theoretical' problem solving. IE., some solutions only look simple after you have found them. Your average change manager wouldn't be expected to take a 'Comp Sci' approach to this, or even an engineering approach, (and of course I wouldn't use esoteria like 'poly-whoseit watchyamacallit' in discussions with production staff), but the underlying data complexity has to be dealt with.

I have however come to the (supported) conclusion that
* the current crop of available tools are adequate to the task - if deployed with the right end in mind.
* the core functional value of the CMDB is achievable at reasonable cost.
* a CMDB can be implemented in a scaled manner, with clearly defined functional milestones and returns.
* (corollary) a CMDB can ONLY be implemented in a scaled project carefully aligned to a planned and managed increase in the maturity of the processes it supports.
* A funtionally and cost effective CMDB can only be done after a Service development model has been deployed (with certain mandatory capabilities in place)

Now if I can get someone to trust me with their project.... Smile
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
twohills
Newbie
Newbie


Joined: May 28, 2006
Posts: 6

PostPosted: Fri Jun 02, 2006 7:01 am    Post subject: Reply with quote

when you say "the current crop of tools": there are specialist CMDBs and there are Service Desks (and there are ???). personally i think the inetgration effort to use a specialist CMDB with other tools outweighs any benefits and I would always(?) recommend the 'whatever the service desk vendor says it is' methodology. but I used to work for one of the big integrated-solution vendors so maybe I'm brainwashed. your views?
_________________
Rob England, Two Hills Ltd
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Fri Jun 02, 2006 10:12 am    Post subject: Reply with quote

Actually I was being fairly inclusive.

In my experience there are a number of functions that can be considered separately. Ane these generally fall into the two areas of information architecture and what you might call 'sensibility'.

Most tools, specialist or otherwise have some capability to 'listen to' or 'look at' the various parts of the infrastructure. But of course this is because nearly everything is being built to send out information about itself, and losts of 'agents' have been developed to 'give speech to the dumb'

This is an important capability for a CMDB, as it would be impractical to do the 'inventory' manually.

However, I think this is pretty much the extent of the contribution tools make to the deployment of 'real' CMDBs (I heard one was spotted once, but conclusive proof has not been forthcoming).

The real challenge is in the area of 'information theory' - I wont go too far into it but it has a number of aspects : modelling, ergonomics, entropy, etc....

I call one the 'Map and Terrain' problem: A map is a really effective representation of data because it abstracts the information we want from the terrain. Hypothetically, if you imagined a map that was a detailed as the terrain it would be as easy to get lost on the map as it would the terrain itself.

And staying with the map metaphore the map not only abstracts the terrain but can model it by, a) transforming inforation - like making all the transport routes red, and all retail precincts blue - thereby helping me plan my shopping trip and b) superimposing additional data over the map to extend the usefulness of the information.

Ergonomics intersects with modelling in the area of 'intention' - the effeciency of the map depends on the representational abstractions matching and supporting the intentions of the reader. So a topological map is going to be pretty useless for my shopping trip.

Entropy doesn't apply to the map metaphor - and the best way to think of this is with the catch phrase - 'A computerised mess is still a mess' A big powerful rapidly proliferating and self-perpetuating mess. Wherever you organise measurements into information you pay a price in effort (and therefore time/money) to get that order.

To come back to the CMDB in general, and the question of tools;

Most play an essential role in collecting the data and doing a preliminary transformation of the data into human readable information, or a secondary system-to-system transformation. But to get to this point we pay an 'entropic cost'. We have to pay the piper so to speak. In our environment we have Open View. It has taken months to fine tune the event reporting. Intially thousands of events were being reported by the system (per minute!!!) Existing filters killed a good percentage, but it took a lot of effort to get the noise out of that data stream.

But of course that only accounts for a small percentage of our infrasturcture, and only provides an extremely limited modelling. The information is now 'noise filtered' but has very low Service Management value.

We in 'IT' remain addicted to the 'T' applying technology solutions to our problems. As a result, in most IT organisations the 'I' (Information) is in an appalling state. And every new 'T' we deploy just pumps more information into our addled processes. A report I have from the Butler Group cites the cost of information management being approximately 10 times the cost of technology management. By assessing information overheads using existing financial data in organisations a clear correlation can be seen between the effectiveness of information management and the performance of the organisation financially.

One of the key mantras of management: "reduce variation, increase reliability" applies to information. And every time we deploy another information system we tend to increase variation and decrease the reliability of our information assets. This includes purpose built CMDB tools.

As I implied this is not soley down to vendors where, (ironically), most of the information science expertise in this industry resides.

It is down to IT organisations who want to address their information issues, not by cleaning up the mess, but by deploying yet another massive data generating system that somehow is going to do it for them. (Sounf a bit like an addiction loop to me - I'd dearly love to know what the marginal growth has been in the relationship between spend on technology to provide base functionality and spend onf technology to manage other technolgy has been, say over the last ten years Smile ).

So to go back to my metaphor of the map. The tools will help you produce it, but they are like the surveyors, demographers, geologists, etc., who collect the data sets that will ensure the final result is accurate.

What is then required is 'sound cartography' the ability to take that information and abstract it effectively into a representation that is ergonomically tuned to the intentions of those trying to suppport Service Management processes. Actually it has to be represented in mutilple complimantary models.

I don't know of a tool that does that well at all. Not because it can't be done but because (reflecting market demand) they actually haven't built them with ITSM objectives foremost in the design philosophy. They are asking 'what kind of maps do technology builders' need to find their way around, when a CDMB should be the answer to the question 'what kind of map does a business value-creation-partner need'.

Remember though, on the ground, most managers are not answerable for the cost of information.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Fri Jun 02, 2006 5:55 pm    Post subject: Reply with quote

I am inclined to agree with RJP here. Cutting through to the basics - most vendors actually factor in time to configure their 'Out of the Box' offerings to suit you. So no tool ever gives an immediate solution.

It seems to me that the best we will ever get is a tool that will come close enough to what we want to be useful.

Regards

Ed
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Sun Jun 04, 2006 2:48 pm    Post subject: Reply with quote

twohills wrote:
I'm always intrigued by how hard CMDB is. To my knowledge, after 20 years of ITIL nobody has yet come up with a standard schema, or even a clear methodology for designing a schema. (Finally some of the vendors are on to this just recently). it seems to me 80% of CMDBs should be absoluteluy identical from company to company, and that 80% should be good enough to get an organisation started, even if they grow uniquely from there.

I really feel for people coming to terms with a CMDB. I think we in the ITIL community have done a crappy job of making CMDB accessible and achievable. Not having a go at you personally, but what is a Change Manager in an average firm to make of "polymorphous ontology"? What I mean is that every bit of advice I have seen about CMDB speaks in generalities and concepts. I've not seen much concrete practical advice on how to go about cutting a schema, or what piece of software to put it in and how to do that. In my experience, most CMDBs are defined by an advanced methodology called "whatever the service desk vendor says it is".

When we see surveys of the uptake of the various functions of ITIL, CMDB is almost always the lowest. it is easy to understand why. it's too hard


This is an interesting topic to me, as it is the premise for my company's business model. We realized that CMDB means many things to many people, depending on the role they're involved in. We've also realized that CMDBs that come from infrastructure organizations are typically highly limited and often poorly designed. This is because very vew Infrastructure Engineers, Admins, etc. are schooled in the arts and sciences of data modeling, relational design, sequential design paradigms vs. object-oriented design paradigms, etc. However, most software engineers, developers, etc., who "do" understand the software space, have very limited understanding of the needs of other organizations, such as Infrastructure Engineers, Admins, etc. Therefore, each organization owns valuable piece of the puzzle but no one organization owns or can understand all pieces, easily.

In the financial world, there are products such as FTI, Eagle PACE, and BlackRock Aladdin, that address the standard structure of financial entities, instruments, prices, securities, etc. These, in essence, are the CMDBs of the financial industry. As limited as they are, they represent an attemtp to standardize the modeling of information and the relationships between such information, for the financial industry.

In the IT industry, as advanced as it is, there have been no real attempts to model everything needed by the enterprise, for IT Operations. There have been piecemeal attempts. Most of these attempts focus on limited areas. For example, many focus on Assets and their interrelationships. Others focus on Software and the relationships between source code and the libraries and executables that are constructed. We have attemped to break this barrier and cross multiple boundaries of the organization. Right or wrong, our attempt is "different" and seems to be gaining attention. We are designing, building, implementing and offering what we believe to be a standardized version of "IT", represented by a standard and usable schema, as it pertains to the operations of an organization.

However, this being said, the perfect CMDB would have itemization of any and all entities and allow for the natural capture and management of relationships between and around these entities. It would be... "The Brain"! Our design, has always been about how the mind works, not about how the infrastructure or software needs to be modeled.

If you're interested in seeing a very different implementation for a CMDB, let me know. I can possible set up a WebEx for you. RJP, you're invited.

Anyhow, I hope this information helps.

Regards,
_________________
[Edited by Admin to remove link]
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: Sun Jun 04, 2006 2:51 pm    Post subject: Reply with quote

rjp wrote:

* the current crop of available tools are adequate to the task - if deployed with the right end in mind.
* the core functional value of the CMDB is achievable at reasonable cost.
* a CMDB can be implemented in a scaled manner, with clearly defined functional milestones and returns.
* (corollary) a CMDB can ONLY be implemented in a scaled project carefully aligned to a planned and managed increase in the maturity of the processes it supports.
* A funtionally and cost effective CMDB can only be done after a Service development model has been deployed (with certain mandatory capabilities in place)

Now if I can get someone to trust me with their project.... Smile


Well said, RJP. However, it's "my" project! And I have a significant head start on you! ; )

Regards,
_________________
[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
Page 1 of 1

 
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.