DataPower gateway licensing.
DataPower Gateway is the security and integration gateway that ships both as a physical appliance and as a virtual edition, and the two are licensed in different ways. The appliance is a device; the virtual edition is processor based. The audit risk lives in the boundary between them.
IBM DataPower Gateway sits at the edge of the integration estate, handling security, protocol bridging, and message routing for traffic moving in and out of the enterprise. It has two delivery forms that matter for licensing. The original form is a physical appliance, a hardened hardware unit you rack and operate as a sealed device. The newer form is the virtual edition, the same gateway function delivered as software that runs in a virtual machine or a container on your own infrastructure. Because the function is identical, it is easy to assume the licensing is too. It is not.
The physical appliance
The physical DataPower appliance is licensed and supported as a device. Like the MQ Appliance, it is the unit itself that carries the entitlement, not a count of processor cores inside it. You do not reconcile a physical DataPower appliance against a core based entitlement, and an audit that tries to do so is applying the wrong model. The accounting question for the appliance is whether each unit in operation is covered by a current entitlement and support, and whether retired or redeployed units have been tracked correctly.
The virtual edition
The virtual edition is software, and it follows a processor based model: the cores allocated to each DataPower virtual instance carry value units, on the same core based principle as the rest of the middleware estate. That brings the familiar disciplines back into play. Every running virtual gateway has to be counted, the value units have to match the processor type, and where the instances run virtualized on eligible technology, sub-capacity licensing can hold the count to the virtual cores allocated rather than the full physical host, provided the approved measurement tool is deployed within ninety days, running continuously, with quarterly reports retained. Without that evidence, full capacity is the default.
Where findings appear
- Counting a physical appliance under the processor based metric, or a virtual instance as if it were an appliance
- Virtual edition instances spun up for scaling or testing that were never added to the core count
- Sub-capacity claimed on the virtual edition without the measurement evidence behind it
- A migration from appliances to the virtual edition that left both sets counted, or neither
- Non production gateways assumed free when they require entitlement
How we defend it
The defense draws the boundary cleanly between the two forms. We account for each physical appliance as a device against its own entitlement, and we count the virtual edition instances by cores against the correct value units, holding the sub-capacity position wherever the evidence supports it. Where IBM has applied the appliance model to virtual instances or the processor model to appliances, we correct the mismatch with your records. The outcome is a DataPower position measured form by form, rather than one inflated count built on the wrong metric.
DataPower is one product in two forms with two licensing models. Account for each physical appliance as a device, count the virtual edition by cores with sub-capacity held where the evidence supports it, and watch the migration boundary so a move from appliances to virtual does not leave both counted at once.
Running DataPower appliances and virtual instances?
Our Audit Defense engagement separates the two forms, accounts for each appliance as a device, counts the virtual edition by cores, and corrects any metric IBM has applied to the wrong form.
See Audit 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.