The Search for Truth and Setting the Right Expectations
There are many definitions of Software Asset Management (SAM), but let’s focus on ITIL’s definition for the purposes of this blog as many others have a similar theme/focus. ITIL defines SAM as:
“All of the infrastructure and processes necessary for the effective management, control and protection of the software assets within an organization throughout all stages of the lifecycle.”
The key points in this definition are:
- Scope – understanding “all of the infrastructure”
- Processes – not just technology
- Management – “control and protection…throughout the lifecycle”
From a more general perspective, the primary end goals of SAM typically span one or all of the following: ensuring compliance, mitigating risk of penalties, avoiding security breaches, reducing risk of unplanned costs, and optimizing investments (i.e. lower costs).
All easier said than done, which is the point of this blog. There is no ‘easy button’ for most, regardless of the tools and content. A former co-worker of mine coined the phrase, “SAM is a dark art”, which is apropos for this blog as it implies SAM is much more than a tool or technology. It requires skilled resources and the right technologies to cover the platforms, titles, and license models within scope.
In my experience, many organizations start with unrealistic expectations because they have not been exposed to the challenges inherent in building a SAM program. It is critical to understand the common challenges in order to build a successful and sustainable SAM program.
The most common SAM mistakes
The most common mistakes made by organizations attempting to implement a SAM program can be boiled down to the following three:
- Setting unrealistic expectations when planning or maturing one’s SAM program.
- Not identifying a roadmap (i.e. a phased approach) with a clear and prioritized list of requirements.
- Not performing the proper due diligence with SAM vendors to fully understand what is achievable OOTB vs. what requires customization and/or professional services/consulting. The latter has a significant impact on cost.
Any one of these three can delay or even kill a SAM project.
Indulge me for just one minute with an analogy based upon a true story. The names have been changed to protect the innocent.
Picture SAM as an onion. As you peel back the layers, your eyes begin to water. Soon you realize there are many more layers than expected. As you peel additional layers, the tears really start to flow – until you’ve got nothing left except pieces of onion everywhere, red eyes, and some empty Visine bottles strewn across the floor. Snapping back to reality and off of the onion analogy, you realize many challenges were not anticipated – your management is getting restless because of the growing costs with limited value and you underestimated the level of resources and consulting required because the tool was supposed to automate most, if not all, of the requirements.
Unfortunately, this is a common scenario which prevents organizations from building, establishing and sustaining a successful SAM program. In fact, some of these same challenges occur when implementing a broader ITAM program. You can refer to my prior blog How to Build an Asset Management Program: 7 Keys to Success for more information on the ITAM front.
To help you drive the discussion and begin to set the proper expectations when planning to implement a SAM program, the next section highlights a range of misconceptions and fundamental truths.
Challenges and fundamental truths of SAM
Below is a collection of some of the most common challenges and truths about SAM, which I have seen organizations either ignore or discount over the years. Many of these are the result of organizations jumping in too quickly without any experience, setting unrealistic expectations, and not defining a focused scope with a phased approach (in other words, the three common mistakes identified above):
- No single tool/solution – No single tool can discover all software and the data necessary to measure all license models (i.e. there is no such thing as an OOTB SAM solution for all software). Some tools are better with certain vendors and/or platforms than others. Some vendors bundle and/or partner with other technologies and content to broaden their coverage. For example, on the discovery front, some software requires usage information and/or specific configuration settings (i.e. Oracle database licensing), while on the licensing front, the product use rights (PUR) can be very complex (think MIPs and points based licensing). On either front, very specialized knowledge is required to create and maintain this level of specialization. This is just one factor as to why a phased approach is essential for success.
- Content drives automation – In today’s SAM world, content is a critical success factor. Without it, the onus is on the customer to create and maintain it, which is not practical unless the scope is very limited. Content covers a wide range of areas including, but not limited to, discovery, license models/SKUs/PUR (product use rights), maintenance, and end of life. For example, with product use rights, the default license can be associated to the discovered software, significantly reducing the effort to measure compliance.
- Complex and ambiguous – License models can be complex and ambiguous and they will continue to grow. Datacenter software tends to be the most complex. Some information required to measure compliance may be difficult to collect. Not all vendor terms are clear and/or measurable and new license models continue to emerge. Note: Prior to the purchase of any software, organizations should verify the compliance terms in order to avoid any ambiguity. If you don’t know what to measure, you cannot be confident in your compliance position.
- Standards slow to adopt – The primary standards in this area (ISO/IEC 19770-1, -2 and -3) have been slow to adopt to further enhance automation and reduce the dependency of content services. As adoption grows, these standards (particularly -2 and -3 below) will reduce the dependency on content which is essential today to drive automation and reduce the SAM effort.
- ISO 19770-1 provides a process framework for SAM (note: a great standard to evaluate and baseline your SAM program).
- ISO 19770-2 provides the standard for software tagging (i.e. discovery) which software vendors are slowly adopting.
- ISO 19770-3 standard provides the transport format, which is intended to drive standardization on the entitlements front.
- Cloud complexity – Cloud licensing adds complexity as this is typically (but not always) less of an issue regarding licensing and compliance and more about usage and optimization. Hence, some cloud vendors are getting better at controlling the usage to avoid non-compliance, which shifts the primary focus on the customer to ensure they don’t over purchase (i.e. optimization over compliance) – an improvement over traditional on-premises software. The tools and technology to capture and manage cloud-based software are emerging and will become more prevalent in the next few years to improve optimization.
The devil is always in the details. If you have a limited scope (e.g. Microsoft Windows desktop software), there is less complexity than a scope that covers multiple vendors and/or platforms (i.e. data center, cloud, etc…).
Be cautious of anyone who contradicts any of these fundamental truths when the scope goes beyond a very limited set of titles, vendors or platforms. For those who fall into the latter group, which is typically most, below are a few initial questions to ask vendors in order to quickly identify the depth of SAM solution and the vendor’s knowledge of this space.
|Initial Clarification Questions||Follow-up Questions|
|Does your solution discover all software OOTB?||
|Does your solution normalize all software OOTB?||
|Does your solution handle all license models OOTB?||
|Beyond what has been covered (ex. normalization, signatures, license models), what other content do you leverage to identify software and automate license compliance calculations?||
Note: This is not a comprehensive list of questions, but could be used to identify a number of key areas which are commonly overlooked when evaluating SAM solutions. For a more in-depth SAM evaluation source, please refer to the final section.
Finding the truth
As I complete this blog, I keep thinking of Jack Nicolson in the movie, “A Few Good Men”, when he emphatically says to Tom Cruise from the witness stand, “YOU CAN’T HANDLE THE TRUTH!!!” I’m not sure why I can’t get that scene out of my head, because it conflicts with the intent of this blog. In my experience, it is not that organizations cannot handle the truth – they can. They just need to find and understand the truth before starting a SAM program. So now the question is, “How do I find the truth?”
The best source of truth about SAM is with those who have the real-world experiences of implementing more formal SAM programs. There are a range of sources, but as a software vendor, I prefer to be agnostic on this topic as this is not intended to be a promotional tool, but rather an independent, educational tool. That said, I do feel comfortable referring to several great independent industry organizations including: The ITAM Review, The International Association of Information Technology Asset Managers, Inc. (IAITAM), and the International Business Software Managers Association (IBSMA). All provide great content, guidance and training around SAM.
For example, The ITAM Review provides a solid SAM Tool Selection Kit, which includes an in-depth questionnaire to assist in the process of selecting a SAM tool. This can serve as a great tool for internal discussion on one’s requirements to drive towards realistic goals and expectations.
One last thought to leave you with – if someone was to ask me ‘What one thing should I focus on when establishing a SAM program?’, I would say educate yourself and your organization. Talk to other organizations who have built SAM programs. Find out about their successes and failures (i.e. lessons learned). Information is power. Don’t be afraid to ask questions and challenge generalizations where something may seem too good to be true. In the case of SAM, there is the chance that could happen if you don’t dig deeper. Find the truth!
- Knowledge Management Strategies: Exploring the Long Tail
- What is Legacy Software Modernization? Legacy Modernization Explained
- What is an Operational-Level Agreement? OLAs Explained
- Enterprise Application Software Defined: How Is It Different from Other Software?
- Competitive Benefits of Enterprise ITSM versus Ad-hoc ITSM