Lost in Translation – is there such a thing as standard SAM terminology?

Many of the problems that arise between SAM vendors and customers are due to assumptions about interpretation of SAM ‘jargon’. Many of the terms we use on a day-to-day basis for SAM are generic ones, but have specific meanings in the context of SAM. The problem is, that not everyone necessarily uses them in the same way. In order to avoid confusion, misunderstandings and potential issues, you should develop and share a SAM glossary to ensure consistency.

In my last blog I talked about the need to create good quality, clear RFx documentation. This means minimizing ambiguity: understanding how and where this can arise and what sources of information are available to reference for definitions of critical terms.

Many of the misunderstandings within businesses, across IT and between SAM service providers and tool vendors and their customers stem from an inconsistency in terminology and failure to define clearly what the terms used mean. There have been several attempts to address this:

The issue of what to call what we do has been raised by my colleague Matt Fisher in his earlier blog post  but the terminology issues for SAM/ ITAM/ TAM or whatever we chose to call it run far deeper than just the name of the overall discipline and what we do.

Terminology is particularly problematic with SAM, although there have been recent attempts to introduce terms such as ‘IoTAM’ (Internet of Things Asset Management) and ‘IoTAD’ (Internet of Things Asset Disposal), creating separate activities for the hardware challenges presented by IoT rather than building them into an inclusive ITAM capability.

In other areas (such as Operational Technology) existing terminology has been used e.g. ‘ITAM for OT’. However, it’s when we get into the detail of how we carry out SAM activities that the problems really start to become apparent.

Avoiding misunderstandings

It is therefore important that none of us make assumptions about what we mean when we use common terms such as entitlement, inventory, consumption, usage, utilization, assignment, normalization, reconciliation and the numerous other terms used to describe the activities and data necessary for effective management of software assets.

When it comes to licensing, the issues become even more problematic. The way in which different vendors define terms can vary wildly, so don’t assume that you can use (or measure) licenses from two vendors the same way just because they’re called the same thing. However, here we are concentrating on SAM key terminology only.

While I would urge everyone to look at the sources linked to above and come up with their own set of agreed definitions that they use internally and when in discussion with vendors, auditors, customers and other external stakeholders, we’ve put together a brief list of key terms highlighting the potential issues and suggesting how they might be dealt with.

Consumption – how the software is consumed against license entitlements and the rights and restrictions that these grants as well as metrics it requires measurement against. It’s not enough to know that the software is installed, even if it is licensed on a per-device metric. There are other rights and responsibilities that you need to be able to prove compliance to. The advent of SaaS and Cloud has added complexity here, but in some ways also helped with clarification that it is not the installation that is key to demonstrating compliance, but the full range of metrics that must be measured to show how the license is consumed. Most software licenses involve multiple metrics, and the variety and combinations are almost limitless.

Discovery – although this term could be applied to the work required to locate any information, in SAM it is generally agreed to have the same meaning as commonly used in ITSM, and to refer to the electronic location and identification of digital technology equipment.

Entitlement – this is what proves your right to use the software, sets out the rights and responsibilities, and how you measure your compliance with these rights and responsibilities. It is the software asset that you are managing. Unfortunately, what counts as entitlement varies from vendor to vendor, so it is very difficult to come up with a clear definition. Entitlement documentation can include contracts (often multiple contracts), purchase details, invoices, license certificates, embedded EULAs, use right documentation and online terms accessed via hyperlinks. This is probably the most difficult information to collect as different elements may be held in different places, and SAM teams need to know where they all are, connect to them and extract the relevant metadata. In many cases, older documentation may be in paper format and may have been lost or destroyed. More recent electronic data may not have been delivered centrally and may also be lost or destroyed – and even if retained it may be hard to track down. ISO 19770-3 Entitlement (Ent) Tags have been developed in an attempt to make entitlements easier to manage.

Inventory – this just means a list. It really doesn’t tell us anything. A list of what? There’s a general assumption that when we talk about inventory we’re talking about the data telling us what software is installed on the devices found in our environment, but in some organizations, it may refer to entitlement records. And for many people there’s also an assumption that this is all the information needed to tell us what we need to license. To ensure clarity, this has often referred to as ‘installed software inventory’. SaaS and Cloud have compounded the confusion here, as SaaS is accessed rather than installed (although there may be locally installed components required to access it), and data on software deployed in the cloud may be located and identified in different ways.

Usage – data on whether software is being used, and by whom. Software is rarely licensed based on usage, although there is sometimes a misconception that you only pay for what you use. In general, either installation or deployment is enough to consume a license. Usage data can help an organization understand where software is, or is not, needed and facilitate the recovery and reuse of unused licenses and reduction in support payments.

Utilization – data on how, and how much, software is being used. This data is of particular interest for managing demand for hardware capacity or managing and forecasting Cloud costs. The elastic nature of Cloud allows capacity to be increased and decreased almost instantly, but failure to monitor utilization can result in excessive costs from underutilized capacity.

Assignment – often ignored, but in some cases, there is a contractual requirement to assign licenses to, for example, a device or user. However, assignment has a much broader use within organizations allowing licenses to be allocated to specific business systems, cost codes, legal entities etc. While some attributes facilitate the management of contractual obligations in complex organizations they also allow for accurate chargeback of software costs, as well as accurate TCO analysis of technology and ROI calculations on business systems and processes. License assignment is key to providing technical and financial transparency and supporting effective management of technology costs and risks. As ITAM capability improves, assignment is key to providing the business-focused insights that occur towards the top of the maturity curve.

Normalization – the process of ensuring that all installations and entitlement that relate to the same products are correctly identified as the same product regardless of variations in naming conventions and data available. Multiple attributes are often used to correctly identify products, and errors are frequent when doing this manually as many products can be difficult to identify correctly, particularly where there are multiple editions, versions and bundles. SAM tools need significant databases of recognition data to normalize effectively. ISO 19770-2 software ID (SWID) tags  (see my colleague Peter Bjorkman’s blog post around SWID Tags) have been developed in an attempt to make this process easier, but adoption by software vendors has been inconsistent.

Reconciliation – comparison of entitlement to consumption. This will either confirm that the two match or result in exception reports highlighting where there are too many or too few licenses for the consumption identified, or where software is being used outside of the terms and conditions set out in the license agreement. Reconciliation data forms the basis for remediation and optimization activities.

Building consensus

Build your own glossary of terms, citing sources where appropriate, and ensure that any discussion around SAM, licensing or compliance includes a reference to this and agreement as to the terminology and definitions that are going to be used.

Image removed.

If you want greater insight, why not download Snow’s new eBook of Software Asset Management Basics – Key Components Explained. It gives you a glimpse of what we can expect from SAM today and in the future, and what impact technologies such as the Internet of Things (IoT) and Artificial Intelligence (AI) will have on Software Asset Management.