CMDB Federation Part 5
CMDB Federation Part 3
This is the 3rd in a series of posts dealing with the concept of a Federated CMDB There are three traditional objections to this first application of the word federation:
-
- The database would be huge and performance would be an issue
- The ITSM processes don't need all of that data so why would I mess up the CMDB with information these processes don't require.
- The cost of this consolidation would outweigh the benefit
CMDB Federation Part 2
This is the 2nd in a series of posts dealing with the concept of a Federated CMDB Since I am obviously biased I will start with the application I believe to be the appropriate use of Federation.
The Federated CMDB Part 1
The emerging capability of federating data sources is the biggest boon and the largest potential pitfall that has arisen for the discipline and process called Configuration Management! On the surface this may appear to be a completely contradictory statement. However, as is the case with all good intentions it all comes down to the application. First and foremost, database federation is an absolute must for a successfully Configuration Management Database (CMDB) implementation.
A Risk by Any Other Name is Still a Risk
In keeping with the last post that challenges the artificial separation we have placed between IT and the business I would like to share a personal experience.