On Dec 12, 2013 5:39 PM, "Janie Sprenger" <[email protected]> wrote: > > ** > Does anyone have a definition for what "lifecycle" means in reference to the CMDB attributes that were put into AST:Attributes in 8.1? > > I understand that the BMC.AM fields are considered Lifecycle attributes and non BMC.AM attributes tend to fall under Configuration Management. I am wondering how BMC decides what falls under Asset Mgmt and what falls under Config Mgmt. > > I'm finding it difficult for users to consistently understand the difference between fields that fall under Asset Management and Configuration Management when the GUI they work in is Asset Management. Understandably, fields have a purpose in either practice, but if all the fields fall under one screen, should users need to know the difference? > > Presumably the impact is relatively lessened for the end user when all of their activities are performed from Asset forms and their experience is seemless regardless of field origin. However, some features tend to highlight the difference, such as Audits, where in 8.1 the users will need to know that if they are looking for Status audits, they should check the Lifecycle audit because it's no longer in the CMDB Audit, and so on and so forth. I've also found that having to rework every AIE import to AI to accommodate attributes in both the core forms and attributes form has been long and time consuming. > > I had thought that an easy way to describe Lifecycle information is to say that attributes included in the lifecycle activity phases have the possibility of change during that lifecycle; however, that doesn't really hold up since Part Number falls under lifecycle but I certainly wouldn't say that attribute should change. And it seems the location information isn't in AST:Attributes yet. In addition, it seems that any Asset Management attribute wouldn't really hold up to the change definition when considering things like Purchase Cost, etc. > > So, then I thought, if the definition behind the BMC.AM fields is that the fields are not discovered through Discovery tools then they must fall into the Configuration Management realm. But then how can one justifiably say that the AssetLifecycleStatus should be an Asset Attribute. Wouldn't this field need to be a Configuration attribute available to the core data model for integration and reconciliation between datasets. What if the 'Status' of the CI is no longer on line and has reached the threshold where the organization considers that the item is End of Life - stolen or otherwise. Since the field has moved to AST:Attributes, is no one updating their discovery datasets with the status anymore. Also, I was under the impression that one of the powerhouse selling points about Discovery tools (whether BMC or otherwise) was to minimize interruption by creating Incidents based on down CIs - ?? what now?? > > So, I'm really just trying to find a 'rule' so to speak so that a user can test that rule to identify any given attribute. > > Does anyone have any ideas on that? > > Thanks, > Janie > > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
