Avoiding the perversion of Hardware/Software Assets

Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭
With enough people involved, others will often interpret and see the same items radically differently. Like any enterprise application, Service Manager is no different offering a rather large bevy of classes (Active Directory, System User, Windows Computer, etc.) out of the box and even more as custom items are developed or purchased to extend the platform.

With that said, it feels like there is an overwhelming desire on many fronts to simplify the use of classes as Configuration Items in relating those CIs to Work Items. As some examples:
  • After importing the Citrix management packs to SCOM/SCSM you get the XenApp server class. Just between two analysts one may always be relating IRs to the Windows Computer instead of the XenApp server (class)*
  • After importing Cireson Asset Management, there may be a desire to generalize the concept of what Hardware and Software assets are in the name of simplifying the amount of classes an analyst has to remember to search when relating WI to CI

And it's really the second example is the point of this thread of mine. I would personally say that the definition of a Software Asset is:
  • a piece of software that is installed in the organization that is used to conduct work
But I would not say:
  • a piece of software that is hosted externally, by a vendor, leveraged through a web portal

With that said, I feel like their is a rather clear distinction I'm making. 3rd party hosted solutions are not software assets. But, and this is what I debate often with myself, if they aren't software assets by that logic (that I just invented) then...
  • What are they?
  • Where from a class perspective would they best belong? Would they best be served as Business Service? 
  • Does someone consider their organizations deployed Cireson Portal a Software Asset?

Moving onto Hardware Assets, does it make sense to use Hardware Assets as more of a "parent" style concept? For example, in my Citrix example:
  • The Hardware Asset is a XenApp Server
  • It has a related CI of the Windows Computer
  • The Windows Computer (or Hardware Asset) contains the related Citrix Class/Object


With all of this said, my opinions are by no means set in stone and I am genuinely open to someone setting me right! Hoping to start a discussion to see if there is some common ground we perhaps all agree on? What do you or your organization define as a Software/Hardware asset? Are you reluctantly shoehorning certain items into these classes because there isn't a better place? Are you perhaps a purist and keeping things as tidy is as humanly possible?



*The point of the SCOM/SCSM connector is to auto-relate CIs to Work Items so manual intervention isn't required. But there may be a need to manually create Work Items against select CIs on occasion thus requiring analysts to have certain items committed to memory.

Comments

  • Eric_KrasnerEric_Krasner Customer Advanced IT Monkey ✭✭✭
    We are  currently in the process of implementing CAM and I am struggling a bit with this same concept.  Do we relate CIs to the work items, or in the name of simplicity, relate the HW or SW asset to the work item.  This then has a downstream effect on what we consider SW and HW assets.  Should we then include Server VMs as HW Assets along with the physical servers? VMs aren't truly HW Assets, but I will box myself into a corner if I don't include them.

    How are others handling this?
Sign In or Register to comment.