Our organization is just in the initial phases of building up a CMDB (using Atrium from BCM)....

So the known objects (elements) in our systems haven't been totally mapped to BMC CMDB classes. one thing i am looking at is federating another configuration application (used for automating installations) against the CMDB since the basic data about servers/databases/clusters/so on doesn't need to be duplicated.

Have been studying the class heirarchy from BMC (assuming it follows a general ITIL recommendation about CMDB classes). having trouble identifying the concept of an environment. an environment internally to us is a way of identifying a development or test or production system (collection of all computer systems/application systems/logical entities). it is essentially just a name telling us that "over there" testing or development or actuall production activities are isolated (logically and very often physically).

Personally i wish BMC had more information describing their thought process when defining classes and relationships between classes (i.e. either real world examples or more long-winded explainations). maybe breakdown of common CMDB classes is available in ITIL resources online? any suggestions?

with the base element is the attribute called domain which could be regarded as a lifecycle marker (such as production). however, using a lifecycle to represent an environment (logical grouping) implies that environments have transitional states which is just a characteristic behind the basic idea of an environment class (a logical collection of system components - similar to the concept of a doman in JMX terms). plus i would like to describe an environment as a class not an attribute or property inherent to a base element. this is a reasonable since an environment can exist without relationships to other classes. if simply regarded as an attribute/property then an environment is by default constricted to being constructed in the construction of other objects.

might be missing each other on what an environment is to our organization...

the lifecycle your talking about is great for capturing the state/status of a particular PI. thus an attribute or property of that instance. however, an environment is a logical resource is it's own right and ought to be described as an element (dvs. ApplicationSystem except at a logical level).

environments themselves may contain the lifecycle characteristic. but again an environment is an entity standing for a complete system needed for all applications within a "release" period to execute. thus "production" is an environment where all application live on a particular system resources. and in a test environment called "project XYZ's test system 123" is where all applications/resources necessary to perform testing important to project XYZ for a release happen. and so forth.

Why don't you define CIs to represent the production / pre-prod / test phases of a system and then link underlying CIs to them. i did a project with a customer where they needed to identify where differing versions of both software and hardware into environments. we ended up creating in effect test models where a model CI was linked to underlying CIs.

The driver for this was to ensure that it was easy to create, use and tear down the different environments on a shared set of platforms.as you have indicated, having an attribute against a CI is not good enough to be able to easily group other CIs for control. In effect you need a new class of CI to contain the others.

a new CI class needs to be defined since at least the Atrium (BMC) CMDB doesn't provide a pre-defined class to handle environments. is there anything in a general ITIL CMDB standard that would encapsulate environments?

otherwise any suggests on which CMDB class to extend? for example the ApplicationSystem or System classes? or more a "logical" class?