Informal Brain

If you are interested in some snippets of cmdb advise follow me on twitter and watch for the #cmdb hashtag.  I am live tweeting our quest to go from zero to cmdb in 6 months… I invite you to watch, learn and comment!

So, based on the kind comments of a number of people and a bit of pondering we came up with the following solution.

1. Each service model will be oriented around a single Application Environment (PROD, UAT, SYS, DEV) and then will include dependent CIs such as virtual and physical servers, database instances, application servers, etc..  Each dependent CI will be related to the Application CI using a direct impact type relationship.  (Our topology tools will find the dependency relationships between CIs and also add those to the CMDB).

2. The application CI which is being modeled will have a name like [application]-[environment] (e.g. app1-prod).  This will provide a unique name for each application instance as it exists in different environments.

So, the environment is a unique part of the CI name and could be easily reported out using %Like% type queries.  At some point we may also add an attribute to the Application CI but it is not critical path.

We have a bit of a conundrum with our CMDB implementation. One of our critical pieces of data is the environment each server, database and application/application system participates in. Example environments might be “dev”, “sys test”, “uat”, “prod”. One challenge we have is that a CI might participate in multiple environments. This is especially true with servers which may host dev, and sys test for example.

We have come up with two options. 1.) Create a CI which represents the environment and create a “is member of” relationship between the CI for the servers, applications and databases to the environment CI. OR 2.) Create an attribute on each server, application, or database CI which would be populated with one or more environments (e.g. prod, or dev:sys test).

The major downside of the attribute is it doesn’t do a very good job of managing the one to many relationship. The downside of the CI approach is it creates a monster relationship between every server, application and database and one of the environment CI instances. This relationship keeps showing up in the CI viewer.

Any thoughts from the experts?