Mainframe customers who have adopted or are considering Tailored Fit Pricing (TFP) must manage three key risks. IBM promotes TFP as a simpler model with no peak-hour management, reduced capacity planning concerns, and fixed costs. While this is mostly accurate, the new billing approach introduces different cost drivers that can be difficult to detect until they have a financial impact.
If you have transitioned to TFP or plan to, be aware of these three common risks. With proper visibility, you can manage them effectively.
Risk 1: Flying blind on consumption and paying for it
The problem
Under AWLC, most mainframe teams watched a single number: the monthly R4HA peak. It’s crude, but it’s concrete. Under TFP, your cost accumulates continuously, and every MSU you use contributes to your annual bill. The question is no longer ‘what was our worst hour?’ It is ‘what are we consuming right now, and is it on track?’
Without a real-time view of consumption, you are effectively billing on trust. SCRT reports are monthly snapshots, and by the time you see a problem, you have already paid for it.
Why this is harder than it sounds
IBM provides native monitoring tools that can give you workload-level consumption data, but the problem is cost, since IBM’s monitoring tools themselves consume meaningful MSU. Under TFP, using IBM’s tools to watch your consumption adds to the consumption you are trying to manage.
General-purpose observability platforms (the tools your organization may already use for application performance monitoring) are not built for mainframe SMF data. They either cannot connect to the data sources that matter (SMF records, DCOLLECT, IMS logs), or they require heavy custom integration to do so.
The solution: mainframe-native observability without the overhead
Zetaly Data Platform (ZDP) was built specifically for this problem. It collects mainframe SMF records continuously, enriches the data, and surfaces consumption by workload, application, and product, all using only 0.2% of mainframe resources. The monitoring overhead does not significantly affect the consumption you are measuring.
ZDP dashboards are updated every 15 minutes, giving you a near-real-time view of where MSU is going. For organizations that require more frequent updates (for example, to monitor a critical batch window), ZAC’s dashboard capability provides 2-minute refresh rates alongside its workload automation features.
For teams that do not have an existing business intelligence (BI) platform to analyze and visualize the data, Zetaly Service Intelligence (ZSI) provides pre-built and configurable dashboards on top of ZDP, connecting IT consumption data to business context lacking requiring deep mainframe expertise.
Risk 2: The Dev/Test container ratchet — A one-way door
The problem
If your TFP contract includes a Dev/Test Solution container, you are subject to a billing mechanism that almost no one reads carefully before signing: the container ratchet effect.
Under TFP’s Dev/Test Solution, IBM defines a container size for your development and test workloads. If the R4HA (Rolling 4-Hour Average) of your dev/test workloads ever exceeds that container size (even once, even during a batch run that nobody intended to be expensive), the container permanently expands to the new high-water mark. No mechanism lets you reduce it back.
How it happens in practice
The most common triggers are end-of-quarter data refreshes (copying production data volumes into test environments), large regression test runs, or a new application rollout where test workloads were not capped before they ran. A single unplanned spike at the wrong moment can increase your dev/test container and your ongoing cost for the remainder of the contract.
The solution: visibility before the spike
You can only prevent the ratchet, not reverse it, so your only effective defense is knowing when you are approaching the container boundary before you breach it.
ZDP gives you visibility into dev/test workload consumption at the workload level. If a batch job or test run is trending toward your container limit, you can see it early enough to intervene and defer the job or cap the resources.
ZAC provides the automation layer: it can enforce soft caps on dev/test workloads to prevent them from exceeding defined resource limits, automatically, without requiring a human to catch every spike in real time.
Risk 3: Your consumption today sets your renewal baseline
The problem
Under TFP, your contract baseline is not fixed for life. When your contract renews, IBM draws a new baseline from the last 12 months of SCRT data, the same calculation that set your original baseline.
This creates a compounding dynamic that most TFP customers do not fully appreciate until renewal. If your consumption has crept upward over the contract period (gradually, workload by workload, quarter by quarter), your renewal baseline will be higher than your original one. You will be negotiating from a higher floor.
Conversely, organizations that actively manage consumption throughout the contract enter renewal with a lean baseline. They negotiate from strength.
Why consumption creep happens
The transition from AWLC to TFP frequently coincides with a period of relief. The peak-management pressure is gone. New projects get provisioned without the same scrutiny. Test environments expand. Applications that were carefully constrained under AWLC now run with less oversight.
None of these individual decisions are unreasonable. Collectively, they ratchet up your average monthly consumption and, therefore, your next baseline.
The solution: treat TFP as an ongoing discipline, not a one-time event
Baseline management under TFP is a continuous practice. Organizations that get the most out of TFP preserve visibility and governance from day one of the contract, not just in the months leading up to renewal.
| Practice | What it prevents | Tool |
| Monthly consumption review | Consumption creep going undetected for quarters | ZDP dashboards |
| Workload caps and automation | Dev/test expansion and batch overconsumption | ZAC |
| Application rationalisation | Dormant workloads contributing to monthly average | ZDP + ZSI |
| Pre-renewal optimization window | Entering renewal negotiations from a high baseline | ZAC + ZDP |
The TFP management stack
These three risks have a common thread: reduced visibility. Under AWLC, the monthly peak enforced discipline. With TFP, this mechanism is absent, so organizations must implement deliberate controls.
The organizations that manage TFP well do so with a clear stack:
- ZDP for continuous SMF data collection and consumption visibility (0.2% mainframe overhead)
- ZSI for teams that need BI dashboards without building their own integration
- ZAC for workload automation, soft capping, and dev/test protection
None of these require a large team to operate. The point of the stack is to replace manual monitoring with automated guardrails, which is especially important for organizations with fewer mainframe engineers than they had five years ago.
📌 On observability more broadly: The mainframe observability market includes general-purpose tools from large vendors. Most of these were designed for distributed environments and adapted for the mainframe. ZDP is purpose-built for z/OS SMF data: no adaptation required, and the 0.2% resource overhead reflects that specificity. Under TFP, where your monitoring tools contribute to your billed consumption, that difference matters.
Frequently Asked Questions
What are the biggest TFP risks for mainframe customers?
The three most common risks are: (1) consumption creep with costs accumulating gradually without visibility; (2) the Dev/Test container ratchet with a single workload spike permanently expanding your container size; and (3) a rising renewal baseline, letting consumption drift up during the contract period means you negotiate from a higher floor at renewal.
Can IBM’s own monitoring tools track TFP consumption?
Yes, but at a cost. IBM’s native monitoring tools can provide workload-level consumption data. However, they consume significant MSU themselves which under TFP adds directly to your monthly bill. Purpose-built tools like Zetaly Data Platform (ZDP) provide similar visibility at 0.2% mainframe resource overhead, avoiding this self-defeating overhead.
What is the Dev/Test container ratchet in TFP?
Under TFP’s Dev/Test Solution, IBM sets a container size for your dev/test workloads. If your Rolling 4-Hour Average (R4HA) for dev/test ever exceeds that container, even once, the container permanently expands to the new peak. It cannot be reduced. The only protection is visibility before the breach and automated resource caps to prevent it.
How does TFP baseline renewal work?
When your TFP contract renews, IBM recalculates your baseline using the last 12 months of SCRT data from your current contract period. If your average monthly consumption increases over the contract term, your new baseline and minimum cost floor will be higher. Consumption management during the contract period matters as much as pre-transition optimization.
Is ZDP compatible with existing BI tools?
ZDP exposes enriched data via APIs, allowing integration with Power BI, Excel, and other BI platforms. For organizations without an existing BI platform, Zetaly Service Intelligence (ZSI) provides pre-built, configurable dashboards on top of ZDP that cover ITOps use cases, including workload monitoring, WLM objective tracking, and anomaly detection.
Does ZAC still add value once a customer has moved to TFP?
Absolutely, and for two reasons. First, ZAC’s workload automation capabilities reduce cumulative MSU consumption, which matters for both day-to-day cost management and pre-renewal baseline optimization. Second, ZAC’s soft-capping functionality automatically protects against Dev/Test container expansion. Teams running lean on mainframe staff particularly benefit from ZAC’s ability to enforce consumption policies automatically.