Avoiding the perversion of Hardware/Software Assets
Adam_Dzyacky
Product Owner 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:
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:
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...
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:
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.
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
- 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.
0
Comments
How are others handling this?