Archive for the ‘CMDB’ Category

Why I’m pretty excited about using Neo4j for a CMDB backend

Thursday, December 8th, 2011

Why I’m pretty excited about using Neo4j for a CMDB backend

From the post:

Skybase is my first open source configuration management database (CMDB) effort, but it’s not the first time I’ve built a CMDB. At work a bunch of us built–and continue to build–a proprietary, internal system CMDB called deathBURRITO as part of our deployment automation effort. We built deathBURRITO using Java, Spring, Hibernate and MySQL. deathBURRITO even has a robotic donkey (really) whose purpose we haven’t quite yet identified.

So far deathBURRITO has worked out well for us. Some of its features–namely, those that directly support deployment automation–have proven more useful than others. But the general consensus seems to be that deathBURRITO addresses an important configuration management (CM) gap, where previously we were “managing” CM data on a department wiki, in spreadsheets, in XML files and in Visio diagrams. While there’s more work to do, what we’ve done so far has been reasonably right-headed, and we’ve been able to evolve it as our needs have evolved.

That’s not to say that there’s nothing I would change. I think there’s an opportunity to do something better on the backend. That was indeed the impetus for Skybase.

Nothing hard and fast yet, but the start of a discussion about using Neo4j and Spring Data for a configuration management database.

When used with information systems, topic maps are the documentation that everyone wishes they had but were too busy to write. Think about it. Everyone intends to document the database tables and their relationships to other tables. But it isn’t all that much fun and it is easy to put off. And put off. And put off. And pretty soon, you are either moving up in the company or moving to another company.

But a topic map isn’t dead documentation in a file draw or bytes on decaying drive media. A topic map is the equivalent of a CMDB system that keeps your expertise with a prior system alive for as long as the system lives. And it gives you something to point to for management (they always like things you can point to) as a demonstration of ROI for their investment in the infrastructure.

Because topic maps can document not only what you were attempting to talk about (values in your data) but the way you were trying to talk about it (keys/column headers), you stand a much better chance at preserving the usefulness of the data long term.