What’s the collective noun for groundhogs?
As a SAM professional have you ever tried to explain to a layperson what you do for a living? I’m sure you have, we all have to explain when asked.
Personally, depending on how invested I am (or tired) I might just say “I work in IT” or “I count things” or if I think the person might actually be interested then I go a little deeper.
Recently, I was on a dive trip where the conversation between dives evolved into what everyone does to pay the bills. When it came to me I think I said “I work in IT” but the person asking was a little more interested so I explained. When I got to the end that person sat and thought and said “hmm sounds like groundhog day” which got me thinking about the movie of the same name.
I won’t bore you with the definition of what a “groundhog day” actually is, there are many more in-depth definitions like this one which will do an excellent job of explaining it. There’s even a movie about it too.
So, now you know what a “groundhog day” is then you can follow my train of thought when I say that SAM is a continuous series of groundhog days, or at least it should be if you’re doing it right.
Before we discuss the finer points of North American mammals and their relationship to the time-space continuum, let us make sure we all understand what it means to calculate a license position.
Understanding Your Variables
For you to determine your license position for a single software product you need to ascertain 6 key elements:
1. Entitlement Quantity
2. Entitlement Metric
3. Entitlement Term
4. Entitlement Type
5. Deployment Platform
6. Data Collection Method
Entitlement Quantity
What does your contract or contracts state for the product in question? Are you entitled to deploy 1, 10, 100 or 1000 of this product? Your contract is the key here. Read it and register what it says whilst remembering to cross-reference this part of the contract with the small print which may have a clause that either restricts the entitlement (e.g. geographical restrictions) or opens up the entitlement (e.g. grandfathering rights).
Entitlement Metric
What does your contract(s) state for the product in question? How is this product to be measured? What is the unit of measurement you care about? There are thousands of units of measurement across the software world and each one is usually designed to ensure maximum revenue for the software publisher. For example, if the software manages the creation of purchase orders the vendor may have licensed the product via a number of users utilising the software, the type of machines the software is deployed on or perhaps the quantity of purchase order lines created in the system. The key here is that all 3 examples are valid for different vendors in the same product space and you will only know which applies to you by reading your contract. If you don’t know what you are supposed to be counting you cannot devise a way to obtain the relevant information you need.
Entitlement Term
What does your contract(s) state for the product in question? Is your license grant a perpetual one or is it a term-based grant? Does it have an expiry clause or a requirement to maintain support for the license to be valid? Are you within the term of your entitlement currently? Does it expire in the future or has it expired? Understanding the spectrum of terms that you have licensed inside your estate can assist you in deciding how to allocate the licenses you are entitled to across your deployments.
Entitlement Type
What does your contract(s) state for the product in question? A “normal” license would be expected to extend the full benefits of the software to the licensee however there are times when a license may have been obtained via a channel which has led to restrictions being placed on that license. For example:
- There are application vendors who sell their products with a database underpinning that application. That database is one the vendor has licensed from a third party. There is a very good chance that the third-party database license in this instance would be restricted to only allow storage of the data being generated via your use of the packaged application. If you log in to that database directly and you start to add your own schema elements or data into that database thereby bypassing the packaged application you would violate the terms of the license. This is sometimes referred to as an “Application Specific” or “Restricted Use” license.
- If you deploy a software product and then make it available to a third party via a multiplexing process you would violate a “standard” license and you may need a “hosting” license.
- A services organisation that wishes to procure a license for a product for its internal use and then utilises that tool to deliver its services to a third party. This is often called a “consulting” or an “MSP” license.
Deployment Platform
Once again, your contract(s) is a good source of information here. What platforms are you entitled to deploy the software against? Are the licenses platform or operating system specific? If you have legacy entitlement you may have licenses which specify the O/S and or chip type you can deploy the software against. It is worth reviewing what the contract(s) states before assuming that all licenses are created equal — they are not.
If you have an estate which takes advantage of virtualisation technology then you should be very sure of your deployment parameters and the restrictions against the specific virtualisation technology you have deployed. Some vendors have policies which, if not adhered to and applicable contractually, can result in large deltas between entitlement and alleged consumption.
Lastly, if you have deployed a software product into a public cloud you may well find that there are specific restrictions on your deployment of the publisher’s software into the public cloud. The restrictions are specific, many and varied.
Data Collection Method
How do you collect the data you need to feed into your calculations? Answering this question will be assisted by your understanding of the first 5 parts of the calculation variables. Once you know what you have to count, where you have to go to collect it and how, you are actually going to count it — then you start on the data collection process.
The following are all valid metrics that exist and may need to be counted:
- total of devices accessing a server
- total users
- total procurement lines created
- total physical cores
- total $ revenue generated by a company over 12 months
- total Gb of data transmitted through a gateway
- total employees employed by a company over 12 months
- total number of custom objects created in a database
- max concurrent connections to a message broker in a 30-day period
- etc, etc , etc
You get the picture. The data you need to collect will govern the method of retrieval. You may need to query a database, consult a network monitoring tool, look at a product console and review the company's annual accounts. Each position calculation will be different and may require different data retrieval methods.
The key to this attribute you need, and the previous three is that they are all defined in the contract. If you don’t have access to your contract then you have a problem as you cannot definitively say what you need to be measuring!
Calculating Your Position
Once you have the elements collected together and you have factored in any wider contractual, commercial or organisational facts, you can calculate your position for the specific product you are concerned with.
It can be as simple as that.
However, it doesn’t stop there. That position you just calculated is for a single product at a single point in time. The longer you leave between calculations of that position, the more likely that deltas will occur and your calculated position will be wrong.
So, when should you calculate your position for that product? Daily, weekly, monthly, annually? When a change is made? How do you catch the triggering event to make sure you calculate the position in a timely manner?
The answer to the position measurement cadence question should ideally be “as often as possible”. The greater the frequency of measurement the more likely you are to be able to identify deltas and (hopefully) catch a problem early.
So, as my diving chum exclaimed, counting the factors necessary to calculate a license position on a cadence which delivers meaningful estate management agility could quite well be described as a “groundhog day”.
Collective Nouns
In the sections above we discussed the necessary activities and data elements which need to be gathered to calculate a valid license position for a single product from a single vendor.
No organisation has a single product from one vendor — most have many many products from multiple vendors. Some organisations have thousands of software products from hundreds of software vendors.
Now imagine the process to calculate a single product and then do it repetitively at a meaningful cadence coupled with the need to do the same thing for all the vendors and products across your estate on a repetitive basis.
If a single product calculation sequence was a groundhog day then the multi-vendor-multi-product calculations would be a collection of groundhog days.
So, dear reader, I ask you, what is the collective noun for multiple groundhog days?
A repetition? A drudge? A boredom? An excellence? A nerd? A SAM?
Who knows, you tell me.
Summary
What I do know is that, whilst my metaphor is perhaps a little tenuous, the concept is worth considering when trying to explain to your executive sponsors or senior management why SAM is complicated, takes time, commitment and investment yet, when done well is a simple set of repetitive tasks which delivers huge ROI, manages risk and supports wider corporate objectives.
Our industry is guilty of allowing, and in some cases promoting, the dumbing down of what we do so maybe the next time you hear someone say that “SAM is just an ELP” maybe ask them if they know what the collective noun is for groundhog days?
Feel free to contact me or take a look at the Version 1 website for more information on software asset management.
About the Author:
Jason Pepper is the Head of SAM Practice here at Version 1.
