Ongoing Software Compliance: What License Managers Can Learn From the Railways

Best practice

Ongoing Software Compliance: What License Managers Can Learn From the Railways

I have been travelling the length and breadth of the UK over the last couple of weeks meeting with clients and attending events.

Idle time on trains during this period got me thinking about what the software licensing industry can learn from the railways, and in particular, what can be learnt from how the rail transport industry protects its revenue and manages the compliance of travellers (Its amazing where your mind wanders when stuck on a train!).

You may think at first glance, that it is simply one ticket for each journey. But the British railway system (and all other global railway systems) has a myriad of options and ticket variations in order to provide flexibility with different travellers. As with air travel, if you are not fussy about where you sit or when you travel, the price you pay can vary significantly.

This is the same for the software industry. Software licensing provides options and flexibility to different customers with different needs and allows software vendors to differentiate themselves and provide competitive edge.

Newcomers to the software licensing industry are often left bewildered, not by the fact that software licensing is complex, but that consumers of licensing have the responsibility for picking up the pieces and working it all out; “Hang on a minute… you’re the one who sold me this stuff! Why don’t you work it out?”

There is a valid argument for industry backlash over this bizarre attitude to licensing or migration to cloud based options whereby licensing can be a) calculated automatically or b) the service provider or partner shoulders the responsibility of working it all out (see also Software Licensing Bad Behaviour).

Validating your train ticket might involve;

• The date
• The type of ticket (flexible, time specific schedule)
• Peak or Off-Peak / Time of day
• Where I am sat (First Class, Cattle Class)
• My age (child / adult / senior etc)
• Is it just me or the whole family?
• Which route (Through London is a premium option)
• Checking additional evidence (Season ticket, student card etc)

So the seemingly simple process of ‘checking my ticket on a train’ actually involves quite a few data points and calculations.

If you have made it this far with my tenuous metaphor you might be wondering ‘What has all this got to do with licensing software?’

Complex Compliance In an Instant

My point is that the ticket collector was able to scan my ticket and assess my compliance position against multiple data points in a fraction of a second despite the complexity. He managed to do this because:

A)   He knew what he was looking for to validate compliance

B)   He knew where to find the data to prove it

A glance at my age, where I was sat on the train, the time of day and scanning the ticket satisfied all compliance checks.

I believe this is the challenge faced by most license managers when looking to demonstrate a compliance position on software.

The two points are often unclear:

• “What data do I need to collect to demonstrate compliance?”
• “Where on earth do I find that data within my business?”

Incidentally, tools are not the blanket solution here. Process, arm-twisting, having a strategic SAM plan are.

If organisations do know what they need to demonstrate compliance, they commonly don’t know where to find that data on an ongoing and consistent basis.

Begin with the End in Mind

An alternative route to delivery ongoing software compliance:

1. Pick your battles

Prioritize by compliance risk (Likelihood of an audit); total financial exposure (who we spend the most money with) or whatever else is important for you. The Pareto principle applies here; in that 80% of your financial burden and compliance risk is likely to be found in 20% of your software estate.   Trying to demonstrate compliance for every single piece of software in your organisation can only lead to disappointment. In an ideal world every software publisher should be treated equally, but we don’t live in an ideal world with infinite SAM resource and infinite budget. Picking off big targets and delivering compliance will help build momentum in your SAM practice and justify further investment in dealing with the smaller vendors.

2. Build The Report

You’ve picked your top vendor to focus on. Now pick a soft target within that vendor. This will enable you to cut your teeth and build confidence. Build a report of what compliance will look like for that product. Begin with end in mind. So if you were to deliver a report on a monthly, quarterly or yearly basis to the business or your management team that demonstrated ongoing compliance for that product what would it look like?

3. Find The Data

Where do I find the data to populate the report on an ongoing basis? Whose arm am I going to twist to generate that data on a regular basis? How accurate is the data? How will we identify changes?

4. Manage the Exceptions

Identifying changes and taking action on them will deliver ongoing efficiency and streamlined operations.

An Example:

I want to deliver ongoing compliance for one application.

The application in question is installed on a server and the licensing cost is dependent on the number of processors configured within that server.

So my compliance report (my end goal) might look something like this:

A)   Instances: This is how many installations we have of this application. You will need a process to identify if 1) When new instances are installed somewhere in your environment and 2) Existing instances are removed or changed.

B)   Configuration: Number of Processors for each instance

C)   Entitlement: What licenses we have bought for this application? Within your entitlement position you will need to periodically check if the product use rights have changed (Is it still per processor? Are there any caveats by operating system? etc)

D)   Exceptions: If A+B does not equal C – what changes occurred and what processes are we going to put in place to prevent this discrepancy happening again. Some common leakages can be found here. Examples might be – the number of processors was increased on a server without checking for compliance, or someone built a new server without checking for entitlement.

Repeating this process across every application in your business might seem like a daunting task, but identifying the steps required and processes to deliver the report will be very powerful in allowing you to repeat and scale the process. If you are regularly taking positive actions on the exceptions, identifying leaks and fixing them, the benefits of these changes will commonly be felt across your whole software estate.

Some changes you might want to make after delivering this report a few times:

• Maybe we shouldn’t allow users to install whatever they want
• Maybe we should work closely with the deployment team to ensure they know the consequences of their actions
• Maybe we should build a software licensing sanity check into every change request
• Maybe we should negotiate fixed product use rights for applications for our agreements so that we can’t get tripped up mid-term
• Maybe we need an automated software request process

As you can see the necessary changes might be technical, process oriented or cultural.

I can’t guarantee that following these steps will make delivering software compliance as easy as checking a train ticket, but it might help starting the process a little easier.

Can’t find what you’re looking for?