Hi,
I am looking for itil software for small-size business, which focuses on CMDB configuration, change, and release managent.
Our CIs won't be physical Hardware, that could be captured automatically by an asset management system.
We will have a variety of virtuell CIs (e.g. ) in very different categories, some with a lage number of specific attributes. Therefore it is hard to find adequate Tools.
Importent to us is:

- defining of CI categories with lage number of specific and self defined attributes
- defining relations between CIs and dependencies
- comfortable manual input of CI data
- subsequent extensibility for CI categories and attributes
- history of CIs
- different user groups (for readonly access)
- defining of inquiries to show CI with there attributes and dependencies to other CIs
- defining trigger that warn a user group in case of danger (e.g. the ci attribute expiration date is imminent)
- ci attributes refencing to a Software-store

Hi jpgilles,
INFRA seems to be fitting, although it may be oversized.
Thanks! newbe_itil

Hi Guerino1,
the main entities we try to track are software instances, to be exact certification authorities (CA, in PKI), which have several attributes and parent-child relationships. These CA are produzing a variety of types of cerrtificates, which are combined and stored in different hardware or software entities. Therfore we have to track the fitting procedures for producing the certificates, the hardware to be used and attribute of end products.
Thanks
newbe_itil

Why would you need so many customizable attributes to do this? The details of the CAs, themselves, shouldn't be in the CMDB. It's only the identifier and basic information for each that you would have to track. The hardware and software you track is all the same as anyone else's, as everyone in the world is tracking hardware and software.

Any decent CMDB should work for you. You may want to consider what you want out of your CMDB and what your year-over-year total cost of ownership will be, once you throw in your costs for infrastructure, dedicated support, integration to other systems, etc.

we do need so many different attributes to manage the CAs, operations and production, because the attributes are defining what can be produced until when, and under which circumstances. We have to fix it in a database, that shows the the important dependencies.

From the itil concept view, would it be an abuse of the CMDB implementing it the way I intended?

I can't be sure, as I have limited information from you, however, it sounds like you're mixing many different things together. I'd be very careful about what you're modeling and how you're modeling it (not to mention the solution you pick to implement it all). You may be digging your enterprise into a hole that will be very difficult to recover from, once you go down that path.

From the itil concept view, would it be an abuse of the CMDB implementing it the way I intended?

No, but as Frank says, it is a sensitive area.

In my experience, however, I found that the only way to make the CMDB useful from an operational standpoint to the people who own the information in the first place is indeed to create numbers of custom attributes. What you want to do is to eliminate all the excel spreadsheets laying around the office and trade them for an organized repository that many people will have an interest in maintaining. That is really the only way to leverage existing resources to implement Configuration Management.

The downside, as Frank points out, is that you increase risk and you need to have a very strong security model to implement access control on a pretty granular level.

I am pulling my hair right now with Infra. It is nice vanilla, but it is designed for central Config Management resources. I am finding that a bit impractical._________________BR,
Fabien Papleux

just one point, whatever you do please be sure that you can manage the set up and the relationships of all the CI's. Will you hvae all these CI's under change control and will changes made to them be updated in the CMDB. If the answer is no to either or both of these then you will find that the data and relationships becomes out of date and then meaningless so all that effort goes down the pan._________________Mark O'Loughlin
ITSM / ITIL Consultant

btw, I echo Mark's point. If you go for a distributed model, you also need to anchor the responsibility of managing relationships. In order to make that manageable, you can define a policy that says, for instance, that it is the responsibility of the owner of the lower-level CI to manage relationships with higher-level CIs. That way, everybody is engaged at the same level. For instance, Application owners are responsible for maintaining relationships with Services... You can get a little creative but if you can get traction, this is an easy way to assign the work..._________________BR,
Fabien Papleux