Why the Passport Advantage matters.
The Passport Advantage agreement sits underneath most of the IBM software estate. Each Passport Advantage product is licensed under a published metric (PVU, RVU, Authorised User, MVS Concurrent Session) and supported through Subscription and Support, the annual S&S renewal mechanism that keeps the perpetual licence current with version upgrades and code-level support.
The agreement runs under the IBM Customer Agreement (ICA) and, where the buyer holds one, a master Passport Advantage agreement that sets the high-volume terms. The ICA carries the audit clause, the dispute mechanism and the governing-law clause. The Passport Advantage agreement carries the high-volume discount band, the eligibility for sub-capacity reporting and the bundle definitions.
The Passport Advantage construct is unusual in one respect that matters to the buyer: it carries a perpetual licence position. Once an entitlement has been acquired, the right to use the software at that quantity persists in perpetuity, even if S&S is allowed to lapse. The S&S renewal then becomes a renewal of support and upgrade rights, not of the licence itself. The buyer position on the perpetual licence is, accordingly, a property right that the buyer carries forward.
That position has two consequences. Firstly, the buyer can elect to lapse S&S on uneconomic components without losing the licence; the version freezes, but the right to use the version persists. Secondly, the reinstatement penalty if the buyer later wishes to return to S&S is published and material. The decision to lapse must be made with the reinstatement penalty in view.
PVU computation and the processor table.
The Processor Value Unit is the principal pricing metric across the Passport Advantage estate. The PVU is computed by reference to the IBM PVU table, which assigns a PVU rate per processor core by chip family. The PVU rate is set by IBM and revised periodically; the buyer position is the PVU table current at the date of the deployment.
The basic computation is simple: number of cores multiplied by PVU rate per core. The complexity sits in three places. Firstly, the read of cores is sensitive to hyperthreading and to the virtualisation layer. Secondly, the PVU rate per core differs by chip family; the IBM POWER core carries a higher PVU rate than the modern Intel x86 core, which carries a higher rate than the older x86 cores. Thirdly, where the deployment runs on a virtualised partition, the partition allocation, not the underlying physical capacity, may be the basis if the sub-capacity entitlement applies.
The PVU computation should be performed against the table current at the date of the deployment, not the date of the audit. Where IBM has revised the table after the deployment, the buyer position is the rate that applied when the deployment was first made. This is a written term and should be defended on the face of the agreement.
Full-capacity versus sub-capacity.
The default Passport Advantage position is full-capacity. Under the full-capacity read, the PVU computation is performed against the entire physical capacity of the server on which the product is installed, regardless of how much of that capacity has been allocated to the partition running the IBM product. The full-capacity read is the IBM default. It produces the larger number.
Sub-capacity is an entitlement, not a default. To qualify for sub-capacity, the buyer must hold a sub-capacity-eligible product on a sub-capacity-eligible partitioning technology, and must run the IBM Licence Metric Tool (ILMT) to produce the quarterly snapshot that evidences the partition allocation. Where these conditions are met, the PVU computation is performed against the partition allocation, not the underlying physical capacity.
The eligibility list is published. Sub-capacity-eligible partitioning technologies include VMware vSphere, IBM PowerVM LPAR, Microsoft Hyper-V, Solaris Containers and selected others. The product list is the IBM Eligible Sub-Capacity Products list, which is maintained by IBM and revised periodically. Both lists should be checked against the deployment at each quarterly review.
The arithmetic difference between full-capacity and sub-capacity can be material. On a 32-core server running an 8-vCPU partition, the full-capacity computation is the rate against 32 cores; the sub-capacity computation is the rate against 8 vCPUs. On a high-PVU product, the difference between the two computations can run to seven figures on a single server.
ILMT health and the 30-day rule.
The IBM Licence Metric Tool deployment is the condition precedent for the sub-capacity entitlement. Without ILMT in proper health, the buyer reverts to full-capacity. Four conditions are written into the Sub-Capacity Licensing terms and should be defended at each quarterly review.
The 90-day deployment window. ILMT must be live within ninety days of the first deployment of a sub-capacity-eligible product. Where ILMT is deployed later than the ninety-day window, the position between the first deployment and the ILMT go-live is exposed to a full-capacity read.
Agent coverage. The ILMT agent must cover the partitions that carry the sub-capacity products. Where an agent is missing on a partition, the partition is exposed to a full-capacity read. The agent coverage discipline is a continuous review: new partitions appear continuously across a virtualised estate and the agent must be deployed on each.
Scan cadence. The ILMT scan must run at thirty-day intervals or shorter. Where the scan has lapsed beyond thirty days, the period of the lapse is exposed to a full-capacity read.
Snapshot retention. The quarterly ILMT snapshot must be retained for the audit window, which under the IBM Customer Agreement runs to two years. Snapshots should be archived at the close of each quarter and held in an immutable store; loss of the snapshot is, for audit purposes, equivalent to absence of the snapshot.
Admodum recommends that the four conditions are made the subject of a continuous review with a documented quarterly attestation. The attestation should be signed by the IT estate owner and the licensing owner, dated to the close of the quarter, and stored alongside the ILMT snapshot. The attestation costs nothing and produces a clean paper trail that can be presented at the opening of an audit.
Bundle and Flexible Bundle treatment.
A number of Passport Advantage products are sold as bundles. The Information Management bundles, the Tivoli bundles and the historical WebSphere bundles each combine a primary product with a set of bundled components at a single PVU rate. The bundle construct simplifies the procurement; it complicates the audit. The component reads inside the bundle must be understood and defended.
The Flexible Bundle is a related construct. The Flexible Bundle entitles the buyer to deploy any of a set of named components against a single PVU pool, with the components rebalanced between deployments at the buyer’s election. Flexible Bundle reads are particularly sensitive at the audit; the IBM auditor may attempt to read each component separately and to apply the unbundled PVU rate. The buyer position is the bundle PVU rate, not the unbundled rate of each component.
Where a bundle is partially deployed (the primary product is in use but one or more bundled components is not), the bundle PVU rate continues to apply. The buyer is entitled to deploy the bundled components at any time during the term without incremental cost. Conversely, where a bundled component is in use without the primary product, the bundle entitlement does not apply; the component is licensed separately.
The audit defence position.
The IBM audit clause sits in the IBM Customer Agreement. The clause carries IBM’s right to verify entitlement against deployment, the cadence is at IBM’s discretion, the notice window is typically thirty days, the look-back is to the contract date or two years, whichever is shorter, and the buyer is required to provide reasonable cooperation. The clause should be read carefully at the agreement signing and the notice window, the look-back and the cooperation language should be negotiated where the buyer holds the leverage to do so.
The Admodum audit defence protocol runs in seven steps. The protocol is identical in shape to the protocol applied to the Oracle LMS audit and the Microsoft SAM audit, with adjustments for the IBM specifics.
- Receipt and acknowledgement. The notice is acknowledged in writing within seven days. No data is shared at the acknowledgement stage. The audit is treated as a commercial process, not a technical one.
- Scope definition. The product list, the look-back window and the entity list are agreed in writing before the data exchange opens. Scope creep is the principal audit risk and should be closed at the front of the engagement.
- ILMT remediation. Where ILMT health has lapsed, remediation is begun immediately on receipt of the notice. The thirty-day rule is not retrospective, but the buyer position is materially stronger where the going-forward ILMT discipline can be demonstrated.
- Data preparation. The deployment data is assembled internally before any data is shared with IBM. The data is reviewed against the entitlement, the PVU computation is performed, and the audit response position is set before the data leaves the building.
- Data exchange and queries. The data is exchanged through a single channel, all queries are routed through the licensing lead, and all interpretations of the agreement are referred back to Admodum.
- True-up arithmetic. The true-up position is computed at the published PVU rate at the date of the deployment, not the date of the audit. Any back-maintenance or back-support claim is contested on its face.
- Closing memorandum. The audit closes with a written memorandum recording the final position, the remediation actions taken, and the going-forward entitlement. The memorandum is signed by both parties and held in the audit file for the next cycle.
The seven-step protocol is independent of the audit outcome. The protocol works equally well where the audit closes at zero (which it does, on a clean ILMT estate, more often than the IBM auditor’s briefing book would suggest) and where the audit closes with a true-up.
Cloud Paks and the Red Hat overlay.
The Cloud Pak construct is the modern face of the Passport Advantage estate. Each Cloud Pak (Cloud Pak for Data, Cloud Pak for Business Automation, Cloud Pak for Security, Cloud Pak for Integration, Cloud Pak for Watson AIOps, Cloud Pak for Applications) bundles a set of capabilities under a single metric, typically the Virtual Processor Core (VPC). The VPC is the modern replacement for the PVU in the Cloud Pak estate.
The Cloud Pak runs on Red Hat OpenShift. The Cloud Pak entitlement carries a bundled OpenShift entitlement for the workload of the Cloud Pak itself; the OpenShift entitlement does not extend to non-Cloud-Pak workloads on the same cluster. Where the OpenShift cluster hosts both Cloud Pak workloads and other workloads, the OpenShift entitlement must be reconciled separately for each.
The Red Hat acquisition has placed Red Hat subscriptions inside the IBM commercial relationship. The Red Hat subscription metric (subscription per node, per socket-pair, per core depending on the product) is not the PVU; the metric reconciliation between Passport Advantage and the Red Hat subscription model is a separate discipline. The buyer position should be that the Red Hat subscriptions are tracked separately from the Passport Advantage PVU position, with the OpenShift bundled entitlement reconciled against the Cloud Pak VPC count.
The renewal posture.
The Passport Advantage S&S renewal runs annually. The renewal window opens ninety days before the anniversary date; the quote is delivered by IBM; the buyer is expected to issue a PO before the anniversary. Where the PO is not issued, the position lapses to a reinstatement event, the reinstatement penalty is material and is published, and the lapse-to-reinstatement gap leaves the buyer without code-level support during the gap.
The renewal preparation should run on a twelve-month cycle. The 90-day window is the close of the cycle, not the start of it. The Admodum twelve-month cycle covers the entitlement review, the ILMT health review, the bundle composition review, the migration paths off uneconomic components, the renewal anchor preparation and the BATNA position.
The BATNA position is critical and is often missing. The buyer position at the IBM negotiating table should always be informed by a credible alternative: a migration to a non-IBM stack, a lapse of S&S on selected components, a movement of workloads to the cloud-native equivalent, a Red Hat subscription substitution. The credible alternative is not a threat; it is the underlying economic position that allows the buyer to walk away from an uneconomic line in the IBM quote.
The renewal anchor is the price floor that the buyer is prepared to defend at the renewal table. The anchor should be informed by the benchmark price for equivalent functionality (which Admodum can supply from the Benchmarking Programme), by the migration cost of the credible alternative, and by the buyer’s strategic position on the IBM relationship.
Reading list and references.
This paper sits alongside three companion Admodum papers and the IBM practice page. The reading list below presents the companion documents in the order they are typically read in an Admodum IBM engagement.
The ILMT and Sub-Capacity build paper covers the ILMT deployment protocol in depth: the agent coverage discipline, the scan cadence, the snapshot retention regime and the remediation playbook where ILMT health has lapsed.
The Oracle LMS Audit Defence paper sets out the buyer-side audit defence protocol in the Oracle context. The seven-step protocol is the same in shape; the IBM specifics are layered into the IBM section of this paper.
The Microsoft EA Renewal Preparation paper covers the renewal preparation discipline in the Microsoft context. The twelve-month cycle, the renewal anchor, the BATNA position and the alternative-stack framing are the same shape across the Passport Advantage renewal and the Microsoft EA renewal.
For the IBM practice itself, see the IBM practice page and the IBM Knowledge Hub. For the engagement model, see fixed fee, contingency or annual retainer. For the programme that closes the renewal, see the Renewal Programme; for the programme that defends the audit, see the Audit Defence Programme; for the benchmark that anchors the renewal price, see the Benchmarking Programme.
