How to best model “environments” in the CDMB?
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?
Author: Shawn Smith
RE: CMDB conundrum – would a dimensional structure work – the environment CI is your “fact” and your server, database, application, etc. are “dimensions”?
It’s a puzzle that many companies seem to struggle with. My first thought was – each environment IS a CI; model it that way, and then fight with your vendor / support team to create a manageable view.
But in fact – each *combination* is a CI; ie “DEV on JHB001″ or “UAT on UKLON05″. And the ‘environment’ is just a multi-valued attribute of the combination. The environment is not in fact a self-contained entity, although standards for it might be, as might be process roles.
Are you running partitions or virtual machines to split the environments, or are DEV and UAT on the same server running in the same OS instance? (Doesn’t that compromise the goal of UAT?) If they’re separate instances, then you naturally have separate CIs with simple relationships, so I assume not. Even so, you might want to consider creating CIs for server-role as I’ve suggested … the picture might be a lot simpler.
A multi-valued attribute is an awkward thing from the data design point of view, as you say. But data model purity can result in complex views!
An object should be a CI if you want to control changes to it. This includes changes to relationships from & to the CI.
So, if you want to track a change to each of these environments (in contrast to changes of the servers, databases, etc.), they should be CIs, otherwise define them as an attribute as follows:
A server dedicated to DEV –> DEV
A server dedicated to UAT –> UAT
A server with two databases, one DEV & one UAT –> MIXED
– The first database is DEV –> DEV
– The second database is UAT –> UAT
Try not to mess with multi-valued attributes if possible. If you need the list of environments this server impacts, you have to traverse the relationships anyway (you may find that some *** created a system that relies upon a DEV database in production
.
Just my 2 cents.