There is continued, perhaps increasing, confusion in the industry as to the discipline of software asset management (SAM and its subsets software license management (SLM) and software license compliance (SLC). Examples include:
- Statements in public forums such as LinkedIn. For example:
- Software license optimization is SAM, stop over-complicating things.
- SAM is about and for license compliance
- Job postings for ITAM or SAM positions (e.g., SAM analyst), details of which clearly indicate that the position is specific to software license compliance, often for specific publishers. (While SAM professionals need a basic understanding of licensing, their focus is on implementation and governance of the SAM program framework.)
- Publishers’ positioning license compliance audits as ‘SAM’ reviews or services.
- Some technology providers’ positioning of their products as comprehensive ‘SAM’ solutions
- Agreements for managed or outsourced ‘SAM’ services, with vague, general terms and narrow scope, not reflective or comprehensive lifecycle SAM. For example:
- Outsourcer will be responsible for IT asset management, specifically, maintaining an inventory of installed hardware and software.
- MSP will be responsible for fulfillment of approved software license requests, and for license tracking.
Although SAM, SLM and SLC are certainly related, there are important differences in scope and objectives, as well as supporting practices.
The inability (unwillingness?) to differentiate SAM and its subsets is one of the reasons ‘SAM’ initiatives too often fail to meet expectations. This differentiation may be helpful to your organization in successfully planning and implementing your SAM program, including selecting appropriate industry solutions to meet your requirements.
These are simple concepts, but with potentially significant repercussions if not fully understood and applied.
First, a few foundational concepts:
- IT assets are defined as hardware and software acquired from external parties, as well as related services such as maintenance and support. Additionally, services that include access to IT assets owned by an external party, whether or not such access requires installation of software on client devices – e.g., cloud-based services.
Tip: Establish criteria to determine which IT assets are in-scope, why, and with what relative priority.
There are three primary ‘views’ of the IT asset portfolio: acquired, installed and used; data representing each of these views typically resides in different applications, reconciliation is needed to identify discrepancies.
- IT asset management (ITAM) is a program framework (Figure 1) and practices for lifecycle tracking, control and analysis of IT assets (physical), integrated with corresponding procurement, financial, contract, and vendor (fiscal) details.
- Why ITAM? For most organizations, ITAM business objectives include:
- Minimize lifecycle costs, including but not limited to license, support and maintenance.
- Mitigate risks – financial, operational legal and reputational.
- Maximize value/return from IT investments.
- Support IT and non-IT functions – e.g., IT change management, procurement.
Of course, appropriate measures should be established to track and report on both the results (effectiveness) and efficiency of the ITAM practices.
Software asset management (SAM) – the subject of this article – is a subset of ITAM, focused on software assets, licenses and related services, as well as media (physical or digital) by which software is delivered. It is important to differentiate SAM and its subsets, as follows and illustrated in Figure 2:
- Software license compliance (SLC) is focused on avoiding ‘under-licensing’, by ensuring compliance with license entitlements – often with (inadequate) focus on the number of licenses as compared to software deployments. However, compliance must take into account other license
parameters such as device configuration, geographic location, employee/non-employee, and many others.
- Software license management (SLM), including software license optimization (SLO), goes beyond SLC to additionally focus on ‘right-licensing’ – avoiding unnecessary licenses in type, quantity and function. Most organizations are over-licensed for some products in quantity (e.g., Microsoft Project) or in product function (e.g., enterprise versus standard edition). In some cases, the software can be deployed more optimally to reduce licensing requirements and costs – e.g., relocating the software to a smaller server.
- Software asset management (SAM) goes beyond a focus on licenses to additionally focus on the software product (asset) – function, currency, standardization, full lifecycle cost, and more.
Today, many ‘SAM’ initiatives are fundamentally SLC, possibly SLM. Ideally, those practices will expand and mature into a comprehensive SAM program.
Note that basic hardware asset tracking is a pre-requisite for all, particularly SLC, to ensure that the software license is sufficient for the device characteristics (e.g., processors and cores).
A comparison of SAM and its subsets follows:
|Software License Compliance (SLC)
- Ensure not ‘under-licensed’.
- Minimize audit likelihood.
- Minimize audit impact.
- Avoid unbudgeted expense.
- Avoid legal and reputational risk.
- Are we entitled to use the software? Do we have a license?
- Where and how deployed? When, how, and by whom used?
- Do we have enough of the right licenses?
|Software License Management (SLM)
||As above, plus:
- Ensure ‘right-licensed’.
- Avoid unnecessary direct costs (license, maintenance, support).
- Avoid unnecessary complexity.
- Do we have the right licenses?
- Are the licenses optimally deployed?
- Are the licenses used?
- Are direct costs commensurate with value?
|Software Asset Management (SAM)
||As above, with expanded focus beyond licenses to include the assets (products):
- Reduce technological complexity – e.g., through product standardization.
- Reduce lifecycle costs – direct and indirect.
- Maximize value/return.
- Support other IT/non-IT functions.
- Plan strategically.
- Do we have the right products? Are there newer or different products that would better meet the business needs?
- Do we have standard products and versions?
- Do we have functionally reductant products?
- Are the products optimally deployed and used?
- Are the products appropriately supported? (internally and externally)
- Is there a product roadmap? (internal and publisher)
- Are lifecycle costs commensurate with value?
Why does differentiation matter? As with most things in business and life, SAM success depends in part on setting appropriate expectations with stakeholders, and a common understanding of key concepts. More specifically, differentiation is needed in order to:
- Identify expected results (benefits).
- Establish an appropriate plan and budget.
- Establish standard and appropriate definitions – e.g., IT asset vs. license.
- Select/define an appropriate program framework to assess current practice and implement new/improved practices. Within that framework, identify necessary policies, processes, data, technologies and roles/accountabilities.
- Select appropriate resources, with requisite experience and knowledge.
- Provide appropriate training.
Bottom Line: We must understand and obtain consensus on the objectives and scope of our ‘SAM’ initiatives to ensure that we solution appropriately – in all respects (policies, technologies, resources, roles/accountabilities etc.). Proper differentiation within SAM and its subsets will facilitate that understanding and consensus and lead to higher levels of SAM maturity and success.