Posted by: buzina | September 22, 2008

Federated CMDB?


Somehow the “CMDB Industry” keeps me wondering. To set up a CMDB correctly, so that it provides the right information at an acceptable cost, is very hard to do. So why should “federating” (**buzzword alarm**) information make things easier? So what is this federating?

Federation allows you to setup a connection from your CMDB to any other data source and to use that data in your CMDB without importing it. Sounds hip, but why should you do this? Will it:

  • Save you money? No, the cost of data is in managing the data and it’s consistency, not in the storage space.
  • Save you development time? No, the difficult part in your CMDB design is still getting all the information into one data model, so that does not change with federation capabilities. Quote from the CMDBf Vision Paper: “4.3 A common data model is essential for successful federation of data from multiple MDRs.
  • Give you a new exciting capability? Eehm, no not really. The current CMDBs allows you to federate attributes only. This is the most “dull” type of information in a CMDB (CIs and their relationships are much more interesting).

So why should we federate CMDBs? Beats me.

Start thinking about your process!


Responses

  1. “As a BSM vendor, my experience with CMDB customers tells me that the most suitable approach for this type of project it to leverage data directly from the trusted sources through integration, rather than attempting to copy, duplicate or otherwise centralize the data with methods such as ETL. In other words, build a centralized view, not a centralize repository, which of course is a key reason why calling it a configuration management system is more appropriate than calling it a configuration management database.” Read more: http://www.wearebsm.com/managed_objects/2008/05/everyone-wants-a-single-source.html

  2. Hi Frank,

    Is there one such setup, which is working? Across different plattforms and data base types? And not only federating a few attributes, but federating CIs and relationships? Do you have a single example where there are not enormous problems with identifying the same CI in different sources, where CIs usualy have a different life-cycle? Is this CMS still capable of answering complex questions (with such a search spanning multiple systems in the background)?

    By the way, why would your customers ask this? A customer does not care if data is held in the CMDB or if it is federated, they either want to get answers from their CMDB or to realize it with a proper benefit (for the customer, not for the vendor😉.

    So if MO can present me with a single real life customer, which has all of this working and is getting benefits from the federation itself (real-time data over 4 hours – 1 day – 1 week old data) without having issues with it (system availability, ability to perform complex queries, CI lifecycle issues, etc), I would be glad to propose MO to my customers.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: