[colug-432] CMDB, was Re: virtualization, clouds, and infrastructure

[Richard Troth]

> The only successful CMDB's I've seen had these qualities:
> 1) home grown
> 2) built on traditional DBs (mostly relational)
> 3) tightly integrated to the mechanism that actually makes the change
> 4) weren't called a CMDB


Amen!

I have worked for software companies as well as "customer shops".  One
employer put substantial people and resources into their CMDB product.
 I thought then that it was a grand mistake.

Jonathan's right.  CMDB has to be home-grown because it has to fit in
with >your< plans and policies for handling the systems (the mechanism
that actually makes the change).  Even flat files are better than
vendor CMDB if they're home grown.

-- R;   <><






On Fri, Dec 17, 2010 at 01:15, Jonathan Hogue <jon at hogue.org> wrote:
>> On the devops toolchain mailing list CMDBs came up a while back and if I
>> remember right, it is pretty hard to find a good standalone solution that
>> has an API and is open source. What are you using?
>
> I was on a project team at Nationwide that tried to implement 2
> different enterprise CMDBs. Neither one really worked. Also, I worked
> with configuration management on amazon's ordering software.
>
> The only successful CMDB's I've seen had these qualities:
> 1) home grown
> 2) built on traditional DBs (mostly relational)
> 3) tightly integrated to the mechanism that actually makes the change
> 4) weren't called a CMDB
>
> The most successful one I've seen required all changes (server,
> network, code build, deployment) to be specifically requested through
> a home grown web tool, and the completion of the request updated the
> configuration. (Often, the changes were implemented automatically,
> once approved).
>
> I know... Holy Grail, but completely obtainable (but it can't be
> purchased off the shelf.)
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432
>