Environment object within CMDB

[young_matthewd]

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?


thanks in advance

[UKVIKING]

ITIL does care what you call your tables or fields

I am currentlyusing HP SD 4.5

The status field within is a lifecycle field so we are using a Environment field for Live (production) etc
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[young_matthewd]

within the Atrium CMDB class structure...

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.

[UKVIKING]

for config purposes, you want to track a CI through its lifecycle

ordered
purchased
installed
etc...
disposed

the lifecycle field would tell the SD, and the other process whether to do anything if the CI is involved in a change, incident etc


when the lifecycle state changes...,there should be a change associated with it

beyond that... how you structure the table ... field size names etc... db is db
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[young_matthewd]

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.

[Cotswolddave]

Hi young matthew

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.

dave

[young_matthewd]

so basically what is being said here is that...

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?