Looking for pragmatic CMDB solution [closed]

Question

I need a solution to catalog a number of applications in our company (more than 100 less than 1000).

Right now we are using a spreadsheet and for each app we fill in name, short description, contact person and maintainer (internal or vendor). The puspose is to use this list for IT planning and incident management (impact estimation, etc.) In order to do this, as a minimum we need to start adding relations like 'depends on', 'part of' or 'supersedes'. It would be also useful if a future solution would allow tagging, adding indexed key-value pairs, comments and attachments to each entry.

We will NOT want to discover all deployed instances of the applications, manage configuration settings, integrate monitoring have complex security settings and get burried in meta-meta-schemata. Anything that requires a dedicated administrator is already too heavy.

We have the following non-functional requirements:

• Should allow multiple users to work concurrently on it
• Every change should be versioned
• Easy export to XML or some other easy to parse format

So far we have considered the following:

• Put the spreadsheet on a Confluence wiki, where we can edit it via WebDav (and get locking and versioning)
• Use the Confluence wiki since it provides tagging, hierarchy, metadata and links. The only concern is that a wiki is too freeform and it may be difficult to extract the information should we decide to migrate to another system.
• DabbleDB.com - has everything we need, but unfortunately the data should not leave the firewall.
• OneCMDB.org - I am not sure how easy it is to capture ad-hock information and evolve the schema. Would appreciate experiences.
• Zenoss.com - haven't checked it yet. Looks too focused on network management.
• Lightweight registry (Mule Galaxy, WSO2 Registry) - not sure if this is the right tool for the job, though they offer a lot of the facilities we need (attributes, labels, versions, lifecycles).
• BMC Atrium - complex, corporate politics would require a number of unnecesarry procedures. Unless it offers some huge benefit, we'd rather stick with opensource.

I'm interested on feedback/ideas from people that have successfully gone through a similar endeavor or have experience with some of the approaches above. Also, I would appreciate advice about common pitfalls and recommendations.

Answer 1

This is tailor-made for a nice, simple web-app framework. Pick your favorite framework. Define your simple data model for applications. Migrate your spreadsheet. Add your other relationships (depends-on, supersedes, part-of) and evolve your application.

Any good web-app framework will have pleasant data mapping for this simple set of data.

It's a good skill-builder. It can be a good Proof of Concept for introducing a new web application framework into an organization.

---

It's hard to avoid "infrastructure" issues. A purpose-built asset management tool is -- generally -- large and complex. Even CalemEAM is rather complex.

Since you have a lot of applications, I was guessing that you already had a web application framework and some skills in using it. From your comment, however, you make it sound like there is no preferred web app. framework.

That causes me to guess that perhaps your 100's to 1000's of apps are a mixture of desktop software and web apps built with no consistent easy-to-live-with framework.

I'm a python bigot, so I'm not familiar with any of the web frameworks you've suggested. The most important source of technical direction should be the folks that built these 100's to 1000's of apps -- what web framework are they using? Which one do they wish they were using? If they were starting a new project (like yours), which one would they use?

You don't want to be the shoemaker's child -- the only one in the village with bare feet. You want your simple little asset management app (it only has 3 tables) to be built with the set of tools preferred by your organization.

---

Okay, with 10% java and 50% vendor systems, there's no "preferred" web app framework.

Choice 1: Pick a Java-based reasonably complete framework. Try using Struts and iBatis as a jumping-off point. Build the minimal tables, the minimlal iBatis mappings from POJO's to the tables. Define the minimal default forms -- one list, one detail for each table. Create the minimal administrative front-end for the minimal set of forms over the minimal set of tables. Write a minimal loader from your spreadsheet to your tables.

Then delete the spreadsheet and never look back.

Choice 2: Learn Python. Use Django. You define the minimal model and use the Django admin interface. You're pretty much done in about 20 minutes. Seriously. Then write the minimal loader from your spreadsheet to your tables. This is a hard sell, so don't sell it, just do it.

Either way, delete the spreadsheet and never look back.

Now, everything has to be done through the web-based database. No excuses. Add all reports to this interface. Do not permit a download to a spreadsheet. Make the app easy to add, change and modify.

Once you can manage the chaos, you get seek forgiveness.

You can never justify this -- you can't prove any ROI on being organized.

Answer 2

It sounds like you need an asset database. You can find many commercially available, but what fun is there in that? If you use MS Access 2007, they have a template for building an asset database that you can download for free.

Answer 3

You can maybe take a look at COSMOS, an implementation of the CMDBf specifications