① Licensing concept · Consumption pricing
Under Tailored Fit Pricing, what a workload is called decides what it costs. New, measured, dev and test, baseline: the same MSU prices differently in each. The definition is a cost lever, and it is verified at renewal and audit.
The classification, not the MSU, sets the charge. And the classification is checked.
Under Tailored Fit Pricing, IBM does not price all z/OS work the same way. The model divides workloads into categories, each with its own eligibility terms and its own charging treatment. The New Application Solution covers approved net new workloads that can sit colocated in an existing LPAR yet be measured independently, so they do not inflate the rolling four hour average of the workloads around them. The baseline workload is the consumption the annual baseline is set against. The Application Development and Test Solution carves out dev and test at a workload specific rate. Each boundary is defined by IBM and verified.
This matters because the same MSU of compute can carry very different cost depending on which category it lands in. Work measured separately under the New Application Solution does not load the baseline floor; the identical work folded into the baseline raises that floor for the whole term. So the classification is not paperwork, it is a pricing decision. And because the categories are verified at renewal and audit, a workload claimed as new or as dev and test that drifts into production characteristics is a reclassification waiting to happen. The matrix below is how to keep the boundaries straight.
Eligibility and approval terms are defined by IBM and vary by contract and machine generation. Confirm the current definitions against your agreement before relying on a classification.
| Workload class | What qualifies | Charging effect |
|---|---|---|
| Baseline workload | Existing consumption the annual baseline is negotiated against | Sets the floor for the term, so a high baseline locks high |
| New application | Approved net new z/OS solution, measurable separately even if colocated | Measured independently, does not inflate the surrounding R4HA |
| Development and test | Separable dev and test workload under the Dev and Test Solution | Workload specific rate, kept out of the production baseline |
| Measured consumption | Metered MSU under the Software Consumption Solution | Billed against baseline plus growth rate, no manual capping needed |
| Reclassified workload | Work that drifted from its claimed class into production | Vendor can move it into the baseline, raising the charge |
A net new 80 MSU workload, deployed colocated in an LPAR that already runs a 450 MSU baseline. Rate R is an illustrative placeholder; actual rates are negotiated and are not stated here. The mechanic is what the classification does to the billable figure.
| Measure | Classed as New Application | Folded into baseline |
|---|---|---|
| Existing baseline (MSU) | 450 | 450 |
| New workload (MSU) | 80 | 80 |
| How the new work is measured | Separately | In the baseline |
| Baseline floor for the term (MSU) | 450 | 530 |
| New work billed at | Its own metered use | 530 × R floor |
Classed as a new application, the 80 MSU is measured on its own and the baseline floor stays at 450. Folded into the baseline, the floor rises to 530 for the entire term, and you pay that higher floor every month whether or not the new work runs. The classification decision, made once at deployment, sets a cost that compounds with the growth rate for years. This is why the definition is negotiated, documented, and defended, not assumed.
The New Application definition is tight and verified. Treating an extension of existing work as new to win separate measurement is a common audit finding, and a reclassification folds it back into the baseline at a higher floor.
A workload carved out under the Dev and Test Solution that starts serving production traffic loses its claim to the carve out. The boundary is checked, and scope creep here is a frequent reclassification point.
Where a classification is unclear, the safe outcome for the vendor is to fold the work into the baseline, raising the floor. Ambiguity left undocumented commonly resolves against the buyer.
A classification made at deployment sets a floor that the growth rate compounds for the term. A wrong call is not a one month error, it is a multi year cost baked into the baseline.
Classify deliberately, document the scope, defend it with evidence.
Treat each workload classification as a costed decision at deployment, not a label applied later. Confirm the current eligibility terms for the New Application and Dev and Test definitions against your own contract, because they are set by IBM and change. Document the scope and the separate measurement evidence for anything claimed as new or as dev and test, and keep SCRT and consumption data current so the classification can be defended with figures rather than assertion. Where a workload sits on a boundary, model both classifications, because the difference is a baseline floor that compounds for the whole term.
Because these definitions are verified at renewal and audit, the licensing context matters: read Tailored Fit Pricing explained for how the baseline is built and the rolling four hour average for what separate measurement protects you from. When IBM proposes or reviews a Tailored Fit Pricing classification, our IBM contract review reads the definitions line by line and our license negotiation team holds the boundary before it becomes a baseline.
A workload's classification determines its charge. The New Application Solution covers approved net new z/OS work measurable separately even when colocated, so it does not inflate the surrounding R4HA. Other classes define baseline, dev and test, and measured consumption differently.
An approved new z/OS solution, standalone or colocated, whose MSU can be measured separately. The definition is narrow and verified, so reclassifying existing work as new is a common audit target. Confirm the terms with IBM.
Because the same MSU prices differently by class. Work measured separately does not load the baseline; folded in, it raises the floor for the term. The classification is a cost decision that compounds with the growth rate.
Yes. Boundaries are verified, and a renewal or audit review can challenge a class. A new or dev and test workload that takes on production traffic is a common reclassification point. Documented scope and current data are the defense.