Skip navigation
All Places > Snow Product Hub > General Licensing Forums > Blog > 2017 > October

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.