When it comes to licensing audits, and as the complexity of IT environments increases, staying on top of your entitlements to mitigate over-deployment will save you time and money. With the complexity of IBM’s software licensing methods, they are no exception. Over the course of IBM’s 100+ year history, IBM has become a conglomerate of many small companies acquired through M&A. As a result, IBM’s Software Licensing is infamously complex with a variety of licensing metrics resulting in millions of audit findings. With over 80 different metrics covering the whole scope of IBM’s products, IBM’s metrics are notoriously difficult to navigate and license properly for. With IBM software commonly deployed in enterprise data centers, understanding the whole slew of licensing metrics and compliance requirements becomes crucial to ensuring you are not paying unnecessary IBM licensing fees. To help you navigate through IBM’s license complexity, let’s get to know some of the metrics and challenges associated with IBM Software Licensing.

 

License Agreements – Understanding Entitlement and Product Use Rights

IBM has recognized the difficulty associated with understanding their product entitlements and have tried to centralize and simplify its licensing by creating the Passport Advantage (IPAA) program. Passport Advantage is a centralized program that uses a common set of agreements, processes, and tools rather than individual agreements for each of its products. However, you cannot solely rely on Passport Advantage alone, as it does not recognize any license purchases outside of the system. Furthermore, because Passport Advantage allows you to download products without restrictions, unmanaged downloads can expose you to over deployment risks. For any legacy purchases, you will need to present the contract or Purchase Order Entitlement (POE) to IBM. You will also need to account for product migrations to get a more complete, and more accurate picture of your IBM entitlements.

In addition to IPAA, IBM uses multiple other license agreements, each with its own set of terms and conditions that are applicable depending on how the product is licensed or deployed in the environment.  Each agreement has its own set of terms and conditions that are applicable depending on how the product is licensed or deployed in the environment. Thus, you’ll want to pay close attention to any changes that impact licensing across agreements.

 

License Models—Varied Metrics and Complexity 

IBM’s software products are frequently deployed across the IT infrastructure and supported on multiple operating system platforms, which increases the complexity of the environment. Managing the vast deployment of IBM products is a daunting task, but for the most part, licensing can be categorized into three major “buckets” – user-based, capacity-based, and other licensing. However, the main difficulty comes from tracking which product goes with the appropriate licensing “bucket.” We’ll now cover the most popular licensing metrics, starting with what is known as Processor Value Unit (PVU).

Processor Value Unit (PVU) – Introduced in 2006, PVU based licensing was created to take the processing capacity of the server into account to determine licensing, rather than relying solely on the number of cores. This change was made to account for the increased processing power of newer technologies, and the gradual shift towards virtualization.

According to IBM, a Processor Value Unit (PVU) is a unit of measure used to differentiate licensing of software on distributed processor technologies (defined by Processor Vendor, Brand, Type and Model Number). In many virtualized environments, certain cores and processors are partitioned, or segmented off to be used for VMs. This means that using the PVU metric under full capacity, a virtual application that only uses 12 out of 24 cores on a server, would still be licensed for all 24 cores under the PVU metric, rather than the 12 cores that are currently in use to support the application.

PVU metric calculations are by far the most complicated and have many moving variables, including the use of virtualization, processor name, server model, number of sockets,  and processor model. IBM created IBM PVU tables assigning core values based on processor architecture, vendor, brand, type, and model number as well as the total cores (number of processors x core per processor). These PVU tables publicly available on their website and show the model, processing capacity, as well as the associated PVU value for the available processing technologies (x86, RISC, and System Z).

Storage Value Licensing—For products licensed by storage data, IBM counts the deployment by ‘Tebibyte’ and not the default ‘Terabyte’, which is 90 percent of a Tebibyte. This confuses many customers as it is a nonstandard way to measure storage.

User-Based Metrics—Be sure not to overlook the user-based metrics, as it is very common to over-deploy IBM’s user-based software since there aren’t any built-in controls to restrict software usage.

Disaster Recovery (DR) Environments—Cold and warm standby servers are not chargeable. Therefore, you need to be careful around IBM’s classification of “hot standby” systems, which are servers performing work such as mirroring of transactions, updating of files, and synchronization of programs, etc. Machines deemed to be running in “hot standby” mode require the appropriate software licenses from IBM.

Full Capacity Versus Sub-Capacity Licensing—To account for increased virtualization, IBM introduced licensing by sub-capacity. Instead of licensing the product for the full capacity of the server or group of servers; it instead measures the capacity in use in the environment. This helps to reduce unnecessary licensing fees as servers are not licensed by their full capacity or total CPU cores.

While sub-capacity is available to customers who agree to the terms and conditions of the agreement, full-capacity licensing is the default unless otherwise agreed in writing with IBM. Given the cost and processing advantage of running IBM software on virtual servers, most businesses prefer to virtualize their IBM environments. However, by default the software is licensed by full-capacity or all processors and cores on the physical host (and server cluster in some cases) must be licensed, as opposed to just the VM or instance running IBM software, which is known as sub-capacity licensing. For a customer to be granted sub-capacity licensing rights, the customer must agree to the terms and conditions of IBM’s sub-capacity agreement.

However, there are two requirements to be eligible for sub-capacity licensing. First, the IBM License Metric Tool (ILMT) must be installed and configured within 90 days of first use of an eligible sub-capacity product. Second, a quarterly report must be produced through ILMT and available to IBM upon IBM’s request.

 

What you need to know about IBM’s License Metric Tool (ILMT)

ILMT is a free tool offered by IBM to measure the metrics necessary for IBM software licensing. ILMT has several functionalities, including software discovery and identification, signature discovery, reports, license usage monitoring, and producing metrics for IBM licensing. In other words, ILMT is similar to a SAM tool that is built specifically around IBM’s PVU based products.

As it relates to licensing, the most important features of ILMT are the reports, license usage monitoring, and licensing metrics. ILMT calculates the maximum core capacity of the server that is available to the installed IBM software, and then determines the number of PVUs or other processor-core entitlements that are required. Given this information, ILMT can produce reports that contain a detailed summary of all the machines in your environment. These are the reports that must be submitted to IBM to be eligible for sub-capacity licensing.

While these features are undoubtedly valuable, they are not perfect. Part of the challenge with ILMT is that it requires significant effort to properly install and configure to capture all of the necessary information. ILMT relies on an agent being installed on a target machine, whether physical or virtual, in order to report deployment data to the ILMT license server. In cases where an agent cannot be deployed to certain enterprise systems, there needs to be a workaround process to gather the installation data from the machines.  Furthermore, many customers find that despite having ILMT installed, their coverage across the environment is incomplete, or they did not properly account for bundled software. The scans themselves can also fail, as there have been known issues with disk space, compatibility, and credentials. Be sure to be aware of these potential pitfalls when using ILMT and consult an expert as needed.

Other leading SAM tools have developed capabilities to measure IBM product use, specifically for the PVU metric. However, if used in place of ILMT, the tool outputs should be reviewed to ensure PVU calculations for both full and sub-capacity licensing are accurate, and product bundling is being addressed by the non-IBM solution.

Given the complexity and dynamic nature of IBM’s licensing models and technology portfolio, it’s very important to understand the licensing metrics to ensure that you mitigate over-deployment, as many customers have been subject to millions of dollars in license fees resulting from an IBM software audit.

 

While this article is not an exhaustive list of IBM licensing metrics or a complete audit defense playbook, we hope that this provides some clarity and insights around IBM’s complex licensing models and ILMT to better prepare for your next software review or IBM renewal. If you would like more information on how Connor’s Software Advisory Services may help reduce your vendor licensing risks and optimize IT spend, please contact us at info@connor-consulting.com.