Skip navigation
All Places > Snow Product Hub > General Licensing Forums > Blog > Author: Rory Canavan
1 2 Previous Next

General Licensing Forums

19 Posts authored by: Rory Canavan


If you fancy getting your Top Gear geek-on, then please head over the ITAM Review UK Conference on 5th & 6th June in Weybridge, Surrey - where the prize on offer from SAM Charter is a Mercedes Benz driving package around their purpose built racing track.  For full details, please go to the link below:


ITAM Review UK Conference – Bring your driving licence! | SAM Charter 

No prizes for guessing it's the SAM graphically-shaped A1 PDF that went before, but what we've done at the SAM Charter website is to put a magnifying glass option on one of our pages, so you can glide and learn to your hearts content.....


SAM System | SAM Charter 


Any questions, please shout.  Don't forget:  You can download your own copy from within Snow Globe, here.  Or equally, you can scoot along to the SAM Charter whitepapers page where you can download this, and other SAM goodies as well.

Dear all,


After a discreet enquiry from one of my business partners if I knew anyone who was a major wheel with Salesforce licensing, I reached out to a contact of mine who implements Salesforce for a living.


The lady concerned then provided me with two very good links:


I'm all about spreading the love, so please use as you see fit.





Rory Canavan

Go-Kart a go-go!!

Posted by Rory Canavan Jan 25, 2018

Huge thanks to Sean Feighery (pictured) and Joseph Powell (away setting lap records at the time of the pic) for waving the SAM Charter flag for the day at the ITAM Review go-karting challenge.  Congratulations to all the teams that took part, this is for a great cause: 


Team SAM Charter :)

Picture the scene:  In the not too distant future, a CIO is “networking” (i.e. out playing golf!) – when walking between shots with his phone set to silent (club rules) he receives a notification from his SAM app that a favoured vendor on the company hit-list has gone out of compliance due to a recent change management event he wasn’t informed of.  An auto-investigate email is sent to the SAM Manager so that he can proactively investigate this immediately, and so the prospect of a rampant deployment team is not an excuse he can offer if his golf swing goes awry.


For the full blog, please visit this link: 


Hi All,


I was recently talking with a prospective client and we were discussing the joys of trying to keep up with the projects and programmes office in respect of new software titles that they might bring to the IT estate.  The blind-siding that ITAM teams often experience here, is not a new story.  Neither too, are the problems that arise once programme installations become BAU (Business As Usual) IT assets.


Standard protocol would suggest that a software testing and packaging process is in place, ideally with a hand-in from the request process, so that if a new title is introduced into the business, a standard means of assessing its suitability can be made.


However, if a project or programme is working to a non-BAU agenda, then perhaps a cunning plan b might be to validate new titles at the Proof of Concept stage.  Clearly, this entails having the ear of the person who oversees projects or programmes, but once that is achieved then at least you stand a better chance of knowing what software will be introduced to your IT estate, when, and whether someone is being lined up to act as a go-to person for the ownership of that new software title come BAU.


As ever, there are no silver bullets in ITAM, but an ounce of lateral thought goes a long way in breaking down such problematic use-cases.

Firstly, may I offer everyone a very happy New Year - I hope 2018 is everything you wish for and more; and that Santa brought you the presents you deserved!


Fresh off the back of the new publication of ISO 19770-1: 2017 I have put together some guidance notes which can be downloaded for free from the link below: 


Feel free to download these notes, and get back to me with any questions.  As stated in the document these notes are NOT a replacement for the Standard itself.

For those who wish to make their Snow technology part of a Software Asset Management System, then ISO 19770-1 has recently been revised and re-published to help organisations achieve this.   NB:  System in this instance refers to the right blend of people, technology and processes.  The 2017 edition supersedes and replaces the 2012 version. 


The first difference to note is that -1 seeks to address ITAM requirements, not just software.  It also aligns itself very closely to ISO 55001 - the ISO Standard for generic Asset Management. Upon initial review, the Standard benefits greatly from being structured like other ISO Management Systems (e.g. 9001, 27001 or 14001) and also in divorcing itself from the Service Management Lifecycle. That's not to say that SAM can't support Service Management, but the lifecycle looks like it has been tailored for SAM/ITAM, as opposed to having been "borrowed" from ITIL. 

Following on from Snow's success at the ITAM Review awards, the ITAM Review kindly gave in to my badgering and let me speak at their Sydney Conference.  A royal blast was had by all, which included fractured toes and faux Irish dancing, and getting to meet Paul Goodson, Andreas Stjernstrom and all the good eggs from Snow based in Sydney.  


The presentation I gave was on SAM & Automation; if you are interested to see the slide deck, then this has been posted in the documents section of this website: 

Rory Canavan

The Ego has landed!

Posted by Rory Canavan Nov 14, 2017

Huge thanks has to go to the judging panel of the ITAM Review Awards.  Either the announcement, (or the Guinness) literally left me speechless for most of the weekend.  Congratulations also has to go to Snow Software for picking up the product of the year award Thanks finally, to Jelle and Julia for their best wishes.

Martin Thompson modelling the latest must-have fashion item


Don't let Martin Thompson's enthusiastic expression put you off - he is thrilled to be wearing a t-shirt with the SAM Charter logo on it (and also some company from Sweden you might have heard of).  Snow and SAM Charter are delighted to be sponsoring Martin with his target of raising money for Sebastian's Action Trust - a privately run hospice for children in the UK.  This ensemble forms part of his clothing for when he will be taking part on his sponsored walk of the Great Wall of China.  


If you would like to get behind this very worthy cause, then please check out the link below: 


Further opportunities to donate will be forthcoming at the ITAM Review Awards, due to take place in Maidenhead on Fri 10th November, where Jelle Wijndelts, Julia Collingburn, myself and 22 others(!) will be arm-wrestling for the ITAM Professional of the Year Award:

I was thinking back to a time when I was studying at University and one of the papers I was writing concerned the role of strategy in company growth.  At the time, it just so happened I picked HP - which was very fortuitous as one week into the assignment Carli Fiorina (the then CEO of HP) had her contract terminated for the "differences in her strategic viewpoint" from the rest of the board.  It was rumoured Carli's termination package saw her receive a $24M pay-out in cash, and a further $24M in HP stock options - and this was when $48M was a lot of money!


There was a lot of vocal displeasure concerning the size of the settlement; not least (as happens when two major companies come together) many staff lost their jobs.


But here's the thing....


Carli didn't negotiate that figure after she was dismissed - she negotiated it before she was employed. 


The point I am coming to is this:  What terms and conditions are you bringing to the table in respect of Software Asset Management?  After all, a contract is a legally binding agreement between two or more parties - it is not a one-way highway for software vendors to gut your company's bottom line.


A slightly wider (and higher) point worth noting, is that just because certain terms and conditions are enshrined in a contract, if a judge deems those terms and conditions unreasonable then they no longer become enforceable - so if a vendor places onerous demands on you through a contract, don't be afraid to return to that vendor and ask "how" you are supposed to adhere to those terms....


Company size is important too; if your spending power is of such a size with a software vendor, then don't be afraid to leverage the scale of the deal in your favour.  I knew of one such company (albeit global) who bought so much software through Oracle, that their audit terms stipulated that a licence shall only be deemed consumed if the software is used (not installed, but used).  Kudos to the procurement staff member who drove that bit of fine print through.


Consider too, the angst caused by your last vendor audit - did you have terms and conditions that you brought to the table that stipulated the "do's and don't" of software vendor behaviour for that audit?  One aspect that always surprises me, is that vendor audits are often prescribed as "lines in the sand“ this is the final and absolute position we agree upon, reflecting our software in your IT estate - but it's amazing how many audits pull out installations and titles that were from before the date of the last audit, and seek reparation for same.


Again, if I were a CIO, I would be stipulating that third parties who represent software vendors can only conduct the current audit, and are not able to conduct a second audit (for another vendor) for another 12 months from the end of the current audit - have you been the victim of revolving-door audits from the same third party?


Increasingly, with the move to the cloud, we are kicking over operational control of our software management assuming that the ISP/SPLA providers are abiding by the terms and conditions of the software they are hosting on our behalf.  If I were a CIO, I would want to make sure that a line or two such as below is included in any hosting agreement I would be asked to sign:


"Any change-activity that could alter this company's licence position must be expressly ratified by an authorised member of this company's IT department BEFORE the change is made.  Any subsequent licence and support & maintenance penalties that result from unauthorised changes will be borne by the ISP".


I'm sure I am just scratching the surface; I would be keen to hear of what other proactive steps people are taking to manage their IT estate through contract T&Cs.

Rory Canavan

Blockchain and SAM

Posted by Rory Canavan Oct 17, 2017

Hi again - a lot of my recent posts have been looking to gain people's opinions on Blockchain.  The Fin-Tech arena seems to be going a little bit nuts for the impact that it could have on its industry; and certain technical writers have started to postulate how could impact IT. A few have even put pen to paper to highlight how it could impact SAM.


I'm just about getting my head around the topic, but as ever, no sooner does one get a concept weighed off, yet another element seems to get tagged on making you wonder if what you had previously acknowledged as understood, remains correct.


So what I shall seek to do is offer a cursory definition of some of the terms that seem to be flying around, and then tie them up together at the end with a view to presenting how I believe this new technical paradigm could impact SAM.


Blockchain:  This is the data motorway by which electronic transactions are conducted.  Essentially blockchain is a shared and distributed database which uses connecting elements of data (or blocks) to reinforce data integrity and security.  If an entity or asset can be represented digitally, then it can be sold via Blockchain - Blocks are created chronologically and added in sequence to the previous chain of blocks, thereby cementing transactions - subject to approval by "Bit Coin Miners".  Once a transaction has been approved; attempted hacks along the route of a blockchain will not be ratified as universal approval will not be granted to a point in time correction to a block - essentially, it's safety in numbers.  A nice 6-minute video introducing this concept can be found here:


Bitcoin:  This is a cryptocurrency that is used in transactions on the Blockchain.  Bitcoins can be programmed to ensure that they are only spent on their intended purchase, or with an approved vendor. The true power of Bitcoins is that they don't have to merely represent currency - they could represent access to an asset.  Again, the above-mentioned link offer food for thought on this concept.


Smart Contracts:  Rolling on from the notion of programmable bitcoins, smart contracts build in terms and conditions into the transaction and form part of the ledger that records a sale.  These conditions (rather like If - Then statements in programming code) have to be honoured before a transaction can be actioned.  I did try to look for a video to offer a deeper review of smart contracts, but nearly all of them appeared to be too cheesy, too boring or too long to include here.


So how can blockchain impact SAM?  If any of you had the chance to check out a previous post of mine on here:  What does good SAM look like.... This!! Then you'll notice that in the middle of the diagram is a Triangle entitled "The Bermuda Triangle of SAM."  This was added to highlight the worst-case scenario of having poor connectivity between:


The Request Process

The Procurement Process

And the Deployment Process



A fuller run-through of this scenario can be read here:  Bermuda Triangle of SAM.  In short, if the software you are requesting, doesn't align with what's bought, and the software bought doesn't align with what's installed, then that space between these core processes are capable of creating the perfect storm for a software vendor audit.  As an aside, if you are expecting ITIL to come to the rescue - then you'll be a long time waiting.  ITIL advocates this scenario as a means of effectively managing software!


So where does blockchain come into the mix for SAM? Well if we consider the traditional approach that might be in place in your organisation today, your request software (probably an extension of your service management suite) your procurement suite, and your deployment suite, are three separate and distinct systems.  What blockchain would seek to do is take these three atoms and form a new molecule which binds these functions through a smart contract. 


Once more, a deeper-dive on this has been offered by Jaime Marijuan Castro - SCM Senior Management Consultant for IBM and can be read here.


So what are the most immediate benefits for SAM if such an approach were adopted? 


Built-in compliance:  Smart Contracts could be used to interrogate the hardware architecture to ensure that the correct level of Cores and Virtual instances did not breach the terms and conditions of the licence.  Furthermore, the smart contracts would prohibit moves or changes that would result in non-compliance occurring later in the lifecycle of the software.


Process Automation & Improved Service Management SLAs:  Deployment of software would only take as long as it took the transaction to be ratified.  The manual running of processes, and the in-built validations to ensure best-practice could become a thing of the past.


IT Expenditure returns to CAPEX:  If as-a-service is showing itself on your profit and loss sheet, then company profits are taking something of a hit that wasn't there in the good old days of on-premise software installation.  However, if your capital is being used to buy bitcoins, then as-a-service purchases can be transferred from OPEX back to CAPEX.


So what are the potential drawbacks to implementing blockchain in SAM?


A change in selling culture:  Software vendors would have to be comfortable with the notion of smart contracts.  To date, vendors have been very reluctant to build protocols into their software that would prohibit or limit use.


Bitcoin volatility:  Traditional currencies are not as susceptible to the peaks and troughs that Bitcoin has recently experienced; so attempting to align actual purchases to favourable Bitcoin trading conditions might result in procurement droughts until the Bitcoin value is more acceptable to the CFO.


Blockchain & Bitcoin maturity:  Acceptance of cryptocurrency and the mechanism by which it can be used has attracted as much good press as it has bad.  The Chinese Government recently called for a ban on ICOs (Initial Coin Offerings) – citing such ventures as "illegal fundraising."  Clearly, governments haven't gotten to grips with this new technical and financial paradigm, and so such reluctance to endorse blockchain could undermine investor confidence.



And yet, software vendors are showing plenty of interest in this technology:  IBM, Microsoft and Oracle have invested much time and research into how blockchain and bitcoin could be exploited.  Indeed, the leaders of the UAE are seeing that blockchain might be the means by which they can abstract themselves away from bureaucracy and an over-reliance on oil (Link).


Steady climbs in the value of bitcoins seem to indicate that the e-currency has the potential to weather financial storms - and in light of Brexit I would be interested to hear from UK-based companies, how many of them are looking to move their currency of choice to anything other than GBP?  One thing is for sure - interesting times lay ahead.

Following on from What does good HAM look like....? (Part 1) we continue with the other key processes and benefits of engaging with this IT discipline.


Loan Equipment Process:  This is a refinement of the Stock Management process, insofar as devices will be kept at a medium specification and a minimum acceptable build, so that loanees don't become too attached to the temporary equipment placed before them while their regular IT devices are on order or going through repair.  Yet again, we should be keeping such devices at a base-build level while they are on the shelf, so that we don't bloat temporary hardware assets with expensive and unused software. 


Hardware Support & Maintenance Process:  Setting Hardware Asset Support & Maintenance is somewhat different from its software cousin, insofar as the business has to assess the role that the hardware assets will fulfil.  Accordingly, based on such a review, the level of cover can be determined and placed alongside the purchase price of the devices.  Another important step that differs from software support and maintenance is to which budget the coverage can be assigned to.  Hardware might be brought into an organisation as part of a programme or project, and so that programme or project bears the cost of the initial coverage sought.  However, once the assets attain BAU status, the support and maintenance will be subject to another (typically annual) review, at which point either the system or service owner will be asked to make a call on which budget the support and maintenance should come from.  Obviously, if devices are brought straight into BAU then this is a step that doesn't need to be taken.  The impact on SAM of this process is bordering on the minimal, but what can it can do for the business (and SAM) is to highlight those assets which are of particular importance to the business.  Therefore, if any SAM services revolve around such VIP devices, then an appropriate level of heightened response can be applied to any software asset queries.  A watch-word for our SAM colleagues here:  Project and Programme implementations of IT services invariably act as a back door to introducing new software - these are the deals I often hear about being made on the golf course or over lunch that has little to do with IT due diligence, but a whole heap to do with massive IT spend, major disruption to BAU operations and Shadow IT.  If you can't be on the golf course, try to make sure your CIO realises the consequences of IT governance by proxy.


Asset Repair Process:  The primary driver for this process is to ensure business continuity; either through the repair of a hardware asset, and/or in handing off to the Loan Equipment Process to ensure that employees are not prevented from carrying out their work.  This process won't impinge on SAM too highly; although your business might require some exception handling for those titles that are locked to devices, and need installing on loaned machines.  Where SAM might get involved, is if the device is declared beyond economic repair, and so hands off to the hardware disposal process.  Once such an activity has been completed, then a destruction certificate should act as a trigger to purge/archive this device from your inventory system (if that is used to gather installation data) and/or from your SAM suite, if SAM suite agents were used to provide installation data.  As previously mentioned, your SAM Suite and/or Inventory System will not know the difference between a missing machine and a scrapped version of same.


Lost & Stolen Devices Process: This process should operate hand in hand with your Joiners, Movers and Leavers Process, so that if it is discovered devices have "gone missing" then they company can take appropriate action to potentially recover the value of the lost/stolen device if it is determined that the liability for the loss/theft lies with the employee.  This should not be an IT-only driven initiative, it is an aspect of management which should have HR engagement, as without referencing the potential recovery of the cost of IT hardware assets from salaries, you could be exposing your company to increased HR strife and counter-claims of "I didn't know that was the routine, nor was it something I agreed to." Stolen devices will require a formal crime number to validate that a potential crime has taken place; lost and stolen devices will need to be updated in a hardware asset/CMDB and even a risk register with their updated status.


Risk register I hear you cry?  The risk in this instance will be access to data; clearly remote wiping routines will need to be enacted for such devices, (thereby reducing our software instance counts (small beer, I know).  But of greater significance will be the shutting down of access to corporate data, and also personal data.  GDPR is on everyone's radar, and having ready processes in place to mitigate data loss will be pivotal to demonstrating proactive personal data management.


Hardware Asset Disposal Process:  It's easy to see how the use-cases can call upon the numerous activities and processes that comprise a hardware asset management lifecycle.  The discussion around asset repair earlier in this article suggested linking with the Hardware Asset Disposal Process if a device is beyond economic repair.  We also have a couple of other use-cases that need addressing through this process, and that would BAU equipment that has reached end of life, and leased equipment is to be returned to the leasing company.  Again, we need to ensure that all devices follow appropriate data-wiping protocols (as governed by Info Sec and GDPR guidelines); but that as with loss and stolen devices, we purge/archive such records from our inventory and SAM suite software.  The issue of leased devices is worth qualifying, as typically such equipment has to be returned in the configuration in which it was supplied; so leased devices don't need wiping - more likely re-imaging should do the trick. 


You might also reach a point where the removal of a particular device removes the last instance of a software title.  This might then call for a refresh of your Supported Software Catalogue - so as to prevent future users from asking for it back.  It's a long-shot, I know, but worth watching out for; particularly in the server space.


Hardware Asset Verification Process: At SAM Charter, we have a similar process for the software side, where we look to verify the software boundary of our SAM scope by comparing Anti-Virus installation data against our software asset inventory data, based on the premise that every device should have both anti-virus and inventory agents installed on them.


The deltas between the comparison should highlight devices that aren't secure, and devices that are not being measured.


A slight tweak on this approach could also be used to compare entries in a CMDB (which, if you remember from our asset tagging process, are introduced encoded from the point of delivery).


A third mix of data from the CMDB could produce 3 delta reports:


  • Devices that are hardware tagged, with AV, but no SAM agent
  • Devices that are hardware tagged, with a SAM agent, but no AV
  • Devices with a SAM Agent and AV, but have no hardware tag/record


The periodic output of such a process should keep information stores refreshed, but also result in some root cause analysis as to why certain devices might have snuck into the company without going through accepted channels.


Physical Audit Process:  Not every company will have all of its hardware assets networked; and so a means of remotely assessing those devices for their existence (as well as the software contained on them) is worth embarking upon. Also, a physical audit process could be used to qualify the location of networked devices if it was important that such machines maintained a physical presence in a specific location.




With licence management becoming ever-more hardware oriented, it would be naïve of anyone to think that software asset management is achievable without paying due regard to hardware assets - particularly in the server/ virtualised space.  However, a little bit of foresight in respect of more traditional hardware assets can also make life easier (and more accurate) for SAM.


Once your company starts aiming at this level of Asset Management, then the use-cases and reporting possibilities can also start to rise in terms of quality and complexity; offering greater benefits to IT and to the business at large.  Furthermore, the prospect of creating and maintaining a CMDB become more like an achievable goal rather than a salesman pitch of just how easy it all is.


Capacity Management and Configuration Management are now no longer theoretical exercises; core data required to plot upper and lower limits of acceptable IT provision to given services can be ramped up based on accurate information.  ITIL now seems plausible, as does value-chain analysis.  The principle and work applied to capacity management for on-prem and physical IT assets will then act as a valuable lesson in scoping capacity for as-a-service assets also.


As always, I would welcome your thoughts on HAM and the tales from the trenches you have experienced in its relations with SAM.  My personal experience has been that too many senior managers somehow expect HAM to follow as a natural extension of SAM - a bit like adding an extra software vendor onto your SAM portfolio. 

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....