① Licensing concept · Consumption pricing
IBM's consumption model trades the rolling four hour peak for a yearly baseline plus a growth rate. Set that baseline well and spikes stop hurting. Set it badly and you lock in a high floor for three years.
A yearly baseline, not a monthly peak. Priced at the table, not in the meter.
Tailored Fit Pricing, which IBM introduced in 2019, is a family of licensing models for IBM Z software and hardware built to move away from the rolling four hour peak, the R4HA, that drives traditional Monthly License Charge bills. Instead of charging on the highest four hour average each month, it sets a negotiated annual consumption baseline and a growth rate, then bills against that. The pitch is predictability: you stop tuning workloads to dodge a peak and pay against a yearly number you agreed in advance.
The model is not one offer but five. The Software Consumption Solution, formerly called the Enterprise Consumption Solution, prices z/OS software on metered MSU consumption against a baseline. The Hardware Consumption Solution adds an always on corridor of capacity on top of the hardware you bought, so short spikes run without a permanent upgrade. The Application Development and Test Solution, the Enterprise Capacity Solution, and the New Application Solution cover dev and test, full capacity, and new colocated workloads. The names matter because only some of them lower a given estate's bill, and IBM decides which one it offers first.
What each solution prices, who it suits, and the buyer trap to watch. Availability and terms vary by machine generation and contract; verify the current offer against your own SCRT data before signing.
| Solution | What it prices | Buyer trap to watch |
|---|---|---|
| Software Consumption Solution | z/OS software on metered MSU against an annual baseline plus growth rate | A baseline set near current peak locks a high floor for the term |
| Hardware Consumption Solution | A subscription corridor of capacity on top of purchased hardware for spikes | Corridor priced for spikes you could schedule away instead |
| Application Development and Test Solution | Dev and test capacity carved out at a workload specific rate | Scope creep of production work into the test container |
| Enterprise Capacity Solution | Full machine capacity at a flat, predictable charge | Pays for capacity you do not consume if utilization is low |
| New Application Solution | New workloads colocated with existing ones, billed separately | Definition of new is narrow and audited at renewal |
One estate, one workload, two ways the baseline gets set. The rate per MSU is an illustrative placeholder R to show the mechanics; actual rates are negotiated and are not stated here. The point is that the number you agree, not the meter, sets the bill.
| Measure | Baseline set at peak | Baseline modeled tightly |
|---|---|---|
| Current monthly peak R4HA (MSU) | 600 | 600 |
| Typical sustained consumption (MSU) | 430 | 430 |
| Annual baseline IBM proposes | 600 | 450 |
| Annual growth rate agreed | 9% | 3% |
| Year one floor billed at rate R | 600 × R | 450 × R |
| Year three floor billed at rate R | 713 × R | 477 × R |
Same machine, same work. The estate that let IBM anchor the baseline on its peak pays a floor 33 percent higher in year one, and the gap widens every year because the growth rate compounds on a larger number. A tightly modeled baseline near sustained consumption, with a low growth rate, is where the model actually delivers. This is why the move to Tailored Fit Pricing is a negotiation, not a procurement form.
Vendors commonly propose a baseline near recent peak consumption, which sets a high floor for the whole term. Once signed, you pay that floor whether or not you use it, so the work happens before signature, in the data.
A growth percentage applied yearly on top of the baseline raises the floor automatically. A high baseline and a high growth rate together can outrun any savings the model promised, which is why both numbers are negotiated, not accepted.
The model removes the incentive to schedule and cap, because the peak no longer sets the bill. That is the convenience, but it also means an estate that was disciplined on the R4HA can quietly give up the savings that discipline produced.
The Hardware Consumption Solution corridor is sold against unpredictable spikes. Some of those spikes are predictable batch or recovery windows that peak shaving would flatten for nothing, so the corridor can monetize a problem you already had a free fix for.
Model both, anchor the baseline low, cap the growth rate.
Approach Tailored Fit Pricing as a modeling exercise first and a contract second. Pull at least twelve months of SCRT data and model the estate under both traditional sub-capacity and the proposed consumption baseline, because the two reward opposite behavior. Anchor the baseline on sustained consumption, not the peak, and push the growth rate as low as the workload trajectory honestly supports. Treat the Hardware Consumption Solution corridor as a last resort for genuinely unpredictable spikes, after checking whether peak shaving would flatten them for free. Build a credible option to stay on MLC so the consumption offer competes against something.
The metric underneath all of this is still capacity, so read MIPS and MSU explained for how the number is built, and group capacity limits for the capping that still matters if you keep MLC. A machine refresh changes the baseline conversation, so see the z16 to z17 question. When IBM puts a consumption baseline on the table, our mainframe license negotiation and cost optimization teams model it against your own data before you sign.
A family of IBM Z consumption and full capacity models, introduced in 2019, that bill against a negotiated annual baseline and growth rate instead of the monthly four hour peak. It spans five solutions, only some of which lower a given estate's bill.
An always on corridor of capacity on top of purchased hardware, commonly available for z15 or later estates with a Software Consumption Solution, that lets short spikes run without a permanent upgrade. Useful for genuinely unpredictable spikes, wasteful for schedulable ones.
Only if the baseline is set near sustained consumption and the growth rate is low. A baseline anchored on your peak locks a high floor for the term. The savings are decided in the negotiation, not the meter.
Model both first. MLC rewards peak management; consumption trades that for predictability. Estates with sharp unavoidable peaks often gain; flat, well capped estates may give up savings they already earned.