- Compliance is a point-in-time concept: Any compliance report produced is subject to the mercy of changes to the IT estate driven via IMAC activities (Installs, Moves, Additions and Changes). Therefore, compliance should be viewed within a band or scale of risk that a business is prepared to live with, rather than a precise value of 100% compliance.
- Compliance can be complex: Increasingly, software vendors are moving away from the “one install = one license” licensing model in favor of a “as-a-service” construct. This allows for a more even pipeline of revenue for a software vendor, and also helps limit piracy/ non-compliance. For those titles that are proving tricky to move to the Cloud, an ever-spiraling level of metrics is being applied to license calculations.
- Compliance does not equal optimization: Merely because you are in the green with a software vendor does not mean that you are sweating your software budget to its maximum value. Software comes in many versions and editions, so make sure the right version and edition of software is deployed against the correct use-case. Additionally, you could be compliant against the software installed, but then have a vast quantity of licenses in a license pool awaiting deployment – that’s dead money until the software is being used.
- Developers are a pain the a*s! From a SAM point of view: Welcome to the Wild West! God help you if you ever have to implement protocols that interact with “the creatives”. Agile should not be a blank cheque for a WTFPL approach to licensing. Getting licensing wrong in this space can prove fiscally very painful indeed.
- Projects are a pain the a*s! From a SAM point of view: Welcome to the Spanish Inquisition! For all you Monty Python fans out there, just as “Nobody expects the Spanish Inquisition”, in the same way no SAM manager wants to be side-swiped by new projects coming onto an IT estate without being given fore-warning of their arrival.
- How do we make a start on being more compliant? Think of what data goes into a compliance report, and then calculate the rate at which each data element changes. The more frequency particular data elements change, the greater the degree of management is required to be applied. Eventually, you will get to the point where you are running compliance positions of different software titles with different levels of frequency because you know which titles are constantly changing, putting you at risk of non-compliance.
- What do you want your compliance report to achieve? We all have that hope that a well-produced compliance report will spur senior management to demand jet-powered remedies to our compliance woes. Unless you make specific recommendations as to what a compliance remedy looks like, don’t be surprised if a senior manager looks at the report and says either:“So what?”, or: “What do you want me to do about this?”. Spell out the course of action you recommend – including what and why of any remedies. Simply being compliant won’t be enough – you will need to draw attention to the financial, reputational and legal penalties that could reasonably ensue if risks are left untreated.
One thing I am proud about in our License Compliance Process in the ITAM Accelerate Process Kit is that it makes suggestions as to where you might like to take a compliance report after it has been produced – the license compliance process triggers a number of different processes including the contract review process, the software recycling & optimisation process and the risk management process. As Simon Sinek’s book (and one of my favourites) states: “Start with Why” – a compliance report in and of itself is not a work of art, but a tool to be wielded to drive change.
