Bundling Relationships in ILMT and How to Model Them
Many IBM components are licensed only as part of a parent product, within a defined scope. ILMT models these as bundling relationships, and when the model is wrong, installs draw down the wrong entitlements. Bundling errors are one of the quietest sources of audit exposure.
What a bundling relationship is
IBM frequently licenses a component as a supporting part of a larger product. The bundled component carries restricted use rights: it is entitled only when used in support of its parent, within the parent's licensed scope. A common example is a database engine shipped with an analytics product, entitled only to support that product and not for general purpose use. ILMT represents this as a parent and child relationship so that the child consumes the parent's entitlement rather than requiring its own.
Why the model matters under audit
When the bundling relationship is modeled correctly, the supporting component is invisible to a standalone license requirement. When it is missing or wrong, ILMT counts the component as an independent install that needs its own entitlement, or worse, an auditor counts a legitimately bundled component as out of scope use. Both directions create findings: one inflates your apparent requirement, the other exposes genuine bundling misuse such as running the bundled database beyond the parent's allowed scope.
How to model bundling correctly
- Identify the parent for every restricted component. Map each supporting install to the product that entitles it before you trust ILMT's automatic assignment.
- Confirm the use stays in scope. A bundled component used beyond its parent, for example a general application hitting a bundled database, breaks the bundle and becomes separately licensable.
- Review automatic bundling decisions. ILMT proposes relationships, but it miscategorizes, so each proposed bundle should be confirmed against the actual deployment.
- Keep the evidence. Document why each component is bundled, so a challenge to an auditor's finding rests on a record rather than an assertion.
The traps to watch
The highest risk pattern is scope creep: a component that started inside a bundle gradually gets used by other workloads. The license position was correct on day one and silently wrong a year later. The second trap is the orphaned child, where a parent is uninstalled or re-platformed and the bundled component keeps running with no entitlement behind it. Both are findable in ILMT if the relationships are reviewed rather than assumed.
Bundling is where directional compliance turns into a hard finding. An auditor will test whether each bundled component stays within its parent's scope, and a mismodeled relationship hands them the finding. Model every parent and child relationship deliberately, confirm the use stays in scope, and keep the rationale, so a bundling challenge can be answered with evidence rather than argument.