Rory Canavan

What does good HAM look like....? (Part 1)

Blog Post created by Rory Canavan on Sep 18, 2017

While the road to good SAM has been given plenty of band-width, and numerous courses have sprung up on what to do with software assets, less attention has been given to what steps should be taken to ensure that the platforms that underpin our SAM efforts are given proper care and attention.


The following two blogs will highlight some of the pertinent aspects relating to Hardware Asset Management as they could impact Software Asset Management.


As ever, if we understand that our ELP is gradually being eroded by IT change, then it is our ability to react to change that seeks to mitigate quality erosion  Rather like our grandmothers keeping the plastic covering on newly-bought furniture, we are not able to shroud our IT estate in a protective layer so as to reinforce the quality of our SAM reports.


If we can't cure change then we should mitigate it.  How do we do that?  You guessed it, through processes!  Thankfully, the processes that are already well documented for SAM, are transposable to HAM also.


The following have been documented in no preferred order, but do offer pointers as to where the hardware element can influence SAM.


Joiners, Movers and Leavers Process:  Many reasons exist as to why we should ensure that our management of hardware assets follows the employee lifecycle.  As I have previously mentioned, no company pays its staff after they have left the company - so why should ex-employees reasonably expect to use company assets once they have left? That though, is the all-too common experience.  Mobile devices, phones and tablets have an uncanny knack of "going missing"  And so, while the individual value of such items doesn't warrant setting off corporate alarms (write-off values of £3,000 are not uncommon) the accumulative effect of such a policy could result in an ever-escalating insurance claim when such assets are declared as "lost".  An additional concern for corporations pertaining to the mismanagement of mobile devices is that of security.  Fines are ever-escalating for the loss of data (through misplaced accessible mobile devices) and regulation such as GDPR would look to impose eye-watering fines for breaches in respect of loss of personal data.


Suddenly, the use-case to track hardware assets in sync with an employee's lifecycle looks like common sense, not merely best-practice.


Asset Request & Deployment Process:  As with a software request process, this process would look to conduct the following checks:


Line Management Approval

IT Approval

Does the hardware asset currently reside in stock?


The added caveat to this would be that the device would then have its status amended from "in-stock" to "live".  With software, we leave such a distinction to be resolved through daily software inventory sweeps - for hardware, such status changes are made at the point of change.  The advantage to SAM in knowing that devices are live on the network is that IT operations/ Service Management will have vetted such devices and pre-qualified them as company assets; thereby assisting SAM in knowing that any software found on those devices will have to be accounted for.  This process also marries up with SAM from the point of view that a pre-requisite of any build scenario should include the installation of an inventory agent - without it, SAM can become an even bigger mountain to climb. 


Hardware Procurement Process:  What checks should we be conducting when the request for a new hardware asset is made?  Eerily enough, very similar checks to a Software Procurement Process:


Has the request come through official channels?

Does the requested hardware fall under a given contract?

Does the requested hardware require support & maintenance?

Does the total amount of the hardware order trigger an Invitation to Tender Process?

Is the requested Hardware on an approved list provided by IT?


One might argue that some of these checks should (rightly) take place at the request process; however, Procurement will have their own due-diligence to satisfy (checks and balances etc.).


Stock Management Process:  An all-too-common misconception within SAM, is that if a device is not live to the network, then the software that resides on that device does not have to be accounted for - e.g. loan equipment on standby, or decommissioned equipment in storage awaiting disposal.




Installation is the key word here.  And so, a ready means has to be in place to integrate such devices into SAM reports.  Of equal significance from the HAM side of life, is to ensure that the correct status for this asset is kept up to date, typically in either a Hardware Asset Register or even a CMDB.  That way, when a device is required to go live, it's location and even position in a store can be pin-pointed.  Greater accuracy equates to a faster roll-out - so customer satisfaction is a primary KPI here.


For the manufacturing devotees, we also have to doff our hat in the direction of JIT (Just in Time) and this is the principle that money in stock is dead money i.e. you can put your financial capital to better use around the company rather than having it sat on a shelf for when it might be needed.  Understanding your company's degree of IT churn will help set limits on what and isn't permissible to have sat on a shelf.  Such a concept cascades to Vendor Management, and how quickly and accurately (in terms of base-software build) a supplier can provide you with your hardware assets.  Setting Service Level Agreements should be in sync with the IT churn mentioned above.


Asset status is a further driver to compliance accuracy and value for money in SAM, as the status of certain assets could relax licence terms and conditions - an accurate understanding of the roles of your devices (particularly in the datacenter) is vital to make maximum use of your software contracts.  A word of warning though:  It may sound obvious, but just because one software vendor rules that development devices are exempt from a production licence of their software, does not mean that other software vendors view development arenas in the same way.  The same warning applies to clustering, failover, high-availability, and any other status of hardware device that crops up in your IT estate. 


A long-held practice within HAM that is skimmed in software asset management, would be the act of tagging.  Hardware tagging is a core component of HAM, and so such a pre-requisite might well be addressed as an SLA with the hardware provider, so that devices equating to specific classes will come with a unique bar-code or even RFiD code on them from the point of delivery.  Once more, a cost-benefit analysis needs to be undertaken to assess whether the hardware reselling company conducts this work for you, or you have spare pairs of hands within the IT team that can perform this duty.  The advantage of asking the hardware resellers to do this, is that the bar code can be used to distinguish a job-lot of hardware assets on the paperwork.  This makes the job of populating a CMDB far easier, and also of tracking hardware items from the goods-in bay through to the IT department, the stock cupboard, or indeed straight to production.


Those items (such as servers) which underpin business and mission critical services, might well benefit from RFiD tags.  Although largely static in nature, it's amazing how easy it can be to lose a server in a datacenter - the analogy of hiding trees in a forest is quite appropriate here.  The significance of getting hardware devices tagged and entered into your CMDB at source, is that devices can be aligned to services.  Between tagging hardware, and inventorying software on those hardware devices, the IT department stands a real chance of being able to offer value-chain analysis to the business of what IT costs, compared to the fiscal benefit a service might deliver.  This is high-end ITAM - but ever more difficult to achieve if such fundamental steps are not taken.


Another aspect that such tagging and identification of hardware assets assists with, is the role that such devices can or do serve.  If key devices have been identified as performing specific roles such as stand-by, back-up or failover, then licensing such devices will be made easier.  Equally, when such devices are called into action, then we will be fore-warned with the knowledge that the devices are properly licensed, and we will know how long we have to retain that configuration within our IT estate before the software can roll-back to the former/ live device - if such licensing restrictions apply.


Furthermore, if we are able to link the software and hardware that provides services to our company, then we can come to the benefit of our architecture and network colleagues also.  Getting a broadcast/ 60,000 ft view of our IT estate is all well and good, but being able to sub-divide that into an ITIL-based view of our IT estate is not as simple as merely installing an inventory agent.


More to follow in Part II....