IBM has been promoting the Tailored Fit Pricing (TFP) model, citing benefits such as fixed costs, no peak-hour management, and reduced capacity planning concerns. However, the new billing approach comes with other hidden cost drivers that can be difficult to detect until they manifest in a real financial impact.
Today, let’s talk about some hidden TFP risks for mainframe customers who are considering or perhaps have already adopted this model. With proper awareness, you can manage these more effectively.
Risk 1: Flying blind on consumption and paying for it
The problem
Teams that use AWLC need to watch a single number: the monthly R4HA peak. In contrast, with TFP, your cost accumulates continuously, and every MSU you use contributes to your annual bill. Under the new pricing model, you don’t need to monitor peak hour consumption rates but pay attention to the cumulative consumption instead.
This can be challenging because SCRT reports provide only monthly snapshots, without giving you real-time data. By the time you see a problem, it is already on your bill.
Why this is harder than it sounds
IBM provides native monitoring tools that can give you real-time workload level data. But the monitoring itself uses up a meaningful amount of MSU, adding to your total consumption.
Your organization may already be using general-purpose observability tools for application performance monitoring. But these tools are not designed for mainframe SMF data: they either cannot connect to the data sources that matter (SMF records, DCOLLECT, IMS logs) or require custom integration to do so.
The solution: mainframe-native observability without the overhead
Zetaly Data Platform (ZDP) was built specifically to solve this problem. It collects mainframe SMF records continuously, while using only 0.2% of mainframe resources. The ZDP then enriches the data and surfaces consumption by workload, application, and product, without increasing the total cost by an appreciable amount.
ZDP dashboards are updated every 15 minutes, giving you essentially a real-time view of where MSU is going. For organizations that need more frequent updates (for example, to monitor a critical batch window), ZAC’s dashboard can provide 2-minute refresh rates, and it comes with 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. This feature allows you to connect IT consumption data to business context, without 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 Dev/Test container ratchet.
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 for this 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 running them. A single mistake can increase your dev/test container and your ongoing cost for the remainder of the contract.
The solution: visibility before the spike
Once you cross the container boundary, there’s no easy way to reverse it. That makes it important to know when you’re getting close, so you can take action before you cross 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, either by deferring the job or capping the resources.
ZAC provides an additional 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, which is the same calculation that determined your original baseline.
Most TFP customers are not fully aware of this compounding dynamic. 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.
Conversely, organizations that actively manage consumption throughout the contract enter renewal with a lean baseline and are able to lower their rate.
Why consumption creep happens
The transition from AWLC to TFP initially brings a bit more flexibility to the workflows by relieving the pressure to manage peak consumption rates. As a result, test environments are expanded, new projects get provisioned without the same scrutiny, and applications that were carefully constrained under AWLC now run with less oversight.
None of these individual decisions are unreasonable, but together, they bring 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 maintain visibility and governance throughout the length of the contract, not just in the months leading up to renewal.
| Practice | What it prevents | Tool |
| Monthly consumption review | Consumption creep going undetected | 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
There is one thing in common between these risks: reduced visibility. AWLC setup forces organizations to keep an eye on the monthly peak consumption. With TFP, this mechanism is absent, so organizations must implement deliberate controls.
The organizations that manage TFP well do the following:
- ZDP for continuous SMF data collection and consumption visibility (with only 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 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. However, most of these were designed for distributed environments and adapted for the mainframe. ZDP is purpose-built for z/OS SMF data, which means 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 expansion, where a single workload spike will permanently expand your container size; and (3) letting consumption drift up during the contract period, which means you negotiate renewal rates from a higher baseline.
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 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 business intelligence 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 that may not have a lot of mainframe staff will particularly benefit from ZAC’s ability to enforce consumption policies automatically.
