Wow, can I write a longer title or what?
The purpose of this blog is to share knowledge that was created, tested, challenged and matured by my company and over 17 years of engagement on ITAM projects.
The nature of Benito's brain (my brain), is to categorize and structure data into a hierarchy of types and or taxonomy.
Employing a common, logical and rational structure for "Control Tables" provide the keys to the solution kingdom that enable efficient reporting, and establish the data architecture to drive automation. Besides, this is a best practice anyways.
<Definition Interlude: CONTROL TABLE = A common, managed and unique information source available within a database table. This table is accessed through the user interface when managing an asset or configuration record. The information within the control table is selected by the user to ensure that a normalized value is utilized when defining an attribute on the asset or configuration. Using a control table approach avoids data variance. This normalized information value makes reporting more efficient by avoiding the creation of complex SQL statements that address multiple iterations of the same value; i.e, HP versus Hewlett Packard, etc. The normalized value within the control tables also enables data VALIDATION of information. The source of data validation is usually from an external data source that is integrated into the CMDB. The integration compares the source value to the control table value within the CMDB through automated workflows. The workflow facilitates the data mapping of the source value to the target value and syntax. These two methods enable the implementation of a common data model within the CMDB.>
While all of this is an interesting subject, what I wanted to share with everyone is the deeper nature of how an asset or configuration is classified and how this classification drives completeness, automation and leveraging of your data model. This is the source of one of my project artifacts "Asset Classification & Behavior". This artifact is created early in a project and drives the design of the product catalog design from that moment forward in a program.
An excerpt of the asset classifications and behavior definitions from the related artifact are provided below.
Of note, a configuration can be a track-able object that is comprised of one or more of these defined natures. This this is a critical topic when designing and implementing ITAM CONTRACT and ITAM CHARGE BACK or cost recovery solution/s.
Now without further adieu, the asset natures...
1. Asset – Object managed in the database that has physical characteristics and is at the highest level of the configuration hierarchy. Can be associated in a parent-child-grand child, or peer to peer relationships.
2. Component – Object managed in the database that has physical characteristic and functions when deployed in conjunction to an asset. A component can be managed as a standalone data element or in a child relationship to an asset.
3. Element – Object managed in the database that has logical (not physical characteristics). An element can be purchased though not physically received. An element may be associated to an asset or component manually or through an automated reconciliation process derived electronic discovery data.
4. Bulk – Object managed in a database that has physical characteristics. Bulk items are managed to the receiving process only. This class is utilized for expendable parts that need to be managed operationally and do not have financial or contractual requirements.
Copyright: RiverBend Solutions, inc. & Benito Esquenazi
