Cloud Pak for Business Automation licensing.
Cloud Pak for Business Automation bundles several capabilities under one entitlement and meters them in Virtual Processor Cores. The convenience of the bundle is also where the audit risk hides. The ratio between a capability and the VPC it consumes, the OpenShift it runs on, and the cluster wide default on non-compliance all decide whether your count is the workload or the whole environment.
One entitlement, several capabilities
Cloud Pak for Business Automation packages capabilities such as workflow, content, decisions, and capture under a single licensable unit. You license the Cloud Pak in VPC and then deploy the components you need from within it. That is genuinely efficient, but it means a single VPC pool is being drawn down by multiple capabilities at once, and the relationship between what is switched on and what is consumed is not always obvious from the console. An audit reconstructs that consumption, and if the deployed capabilities draw more VPC than the entitlement covers, the overrun is the finding.
VPC and the conversion ratios
Each capability inside the Cloud Pak converts to VPC at a defined ratio, and the ratios are not uniform. A heavier capability consumes more VPC per unit of work than a lighter one, so two deployments of the same physical size can carry very different VPC counts depending on which components are running. Buyers who size the entitlement against cores rather than against the capability ratios end up under entitled without realizing it. Confirming the correct ratio for each deployed capability, against the version in use, is the first step in any defensible count.
OpenShift underneath, and ILMT around it
The Cloud Pak runs on Red Hat OpenShift, and the entitlement typically includes OpenShift scoped to that workload. Because the whole stack is metered in VPC, sub-capacity reporting applies, and since Passport Advantage version 11 reaching existing customers on May 1 2023, ILMT is required for VPC products with manual counting no longer permitted. The inventory tool must be deployed within 90 days of first eligible deployment, running continuously, with quarterly reports retained two years. Without that evidence the sub-capacity claim collapses, and for a containerized product the default is unforgiving.
The cluster wide default
For container and Cloud Pak workloads, non-compliance does not charge the node the software ran on. It charges every core in the cluster. A Business Automation deployment that overruns its VPC on part of a large OpenShift cluster can be counted against the entire cluster, turning a modest gap into a finding many times its real size. This is why the configuration evidence matters more here than almost anywhere else in the IBM catalog, and why the count has to be challenged the moment it defaults to cluster scope.
Cloud Pak for Business Automation concentrates exposure at the VPC conversion ratios, the bundled OpenShift scope, the continuous ILMT evidence, and the cluster wide default on non-compliance. A finding here is rarely a single misconfigured node. It is the cluster default applied to a partial gap. Rebuilding the position means confirming each capability ratio, proving the sub-capacity evidence, and refusing the cluster wide count where the workload sat on a fraction of it.
Is a Cloud Pak count defaulting to your whole cluster?
Our Sub-Capacity Defense engagement confirms the VPC ratios for each deployed capability, validates the ILMT evidence, and challenges any Business Automation finding that charges the full cluster instead of the workload.
See Sub-Capacity Defense →The IBM Audit Brief
Audit triggers, ILMT pitfalls, and settlement tactics for IBM software buyers.
Independent, buyer side IBM software audit defense and negotiation. Not affiliated with IBM Corporation.