IBM Tailored Fit Pricing for Z
IBM introduced Tailored Fit Pricing (TFP) to simplify mainframe software billing and offer more predictable costs. For some enterprises, it feels like a “game changer” in reducing MLC volatility; for others, it creates rigid commitments and potential overspend.
This guide explains how TFP works, its pros and cons, and what to consider when negotiating before signing a contract. Read our ultimate guide to IBM Mainframe Licensing (z Systems): Models, Costs, and Negotiation Tips.
1. What is Tailored Fit Pricing?
Tailored Fit Pricing (TFP) is IBM’s alternative to the traditional Monthly License Charge (MLC) model for mainframe software.
Under the old MLC system, you paid for software based on monthly peak usage, measured in millions of service units (MSUs). This often led to surprise bills whenever usage spiked, even briefly. TFP replaces that spiky billing with a more predictable scheme – usually a fixed annual fee or a base subscription plus a variable component.
How TFP Works:
Instead of tracking every peak, you negotiate an annual price for your IBM Z software environment. Think of it as moving to a subscription model for mainframe software.
You commit to a certain spend or capacity, and IBM, in return, gives you more flexibility in how you use the mainframe without constantly worrying about hitting a cost peak.
TFP Variants: IBM offers two primary TFP models to choose from, depending on your needs:
- Enterprise Consumption Model: A usage-based “all-you-can-eat” approach with a fixed annual price covering all your workloads. It’s like a cloud model – you get billed a set yearly amount and can consume as much MSU as needed. This eliminates the need to cap workloads to avoid high costs, as the bill remains predictable regardless of usage. It’s ideal for organizations expecting significant growth in mainframe usage or those wanting cloud-like flexibility on a fixed budget.
- Enterprise Capacity Model: A full-capacity model tied to the size of your mainframe (MSU capacity) rather than monthly peaks. You pay for a predefined capacity level (often based on the hardware or a committed MSU level) at a simplified, discounted rate. This offers maximum cost predictability – essentially a flat rate for your mainframe software as long as you stay within that capacity. It’s simpler than juggling monthly peak bills under MLC, but it requires confidence that your capacity needs won’t suddenly drop.
Both variants aim to smooth out the cost volatility of traditional pricing.
In practice, TFP is a custom contract: you work with IBM to tailor the pricing to your historical usage and projected needs. This means every TFP deal can be a bit different, which is why understanding the fine print is crucial.
2. Benefits of IBM TFP
Adopting Tailored Fit Pricing can offer several compelling benefits for mainframe shops, especially those struggling with unpredictable software bills.
Here are the key advantages:
- Predictable Costs: The biggest appeal of TFP is cost predictability. You no longer get shocked by a huge invoice due to an unexpected MSU spike. With a fixed annual price (or a known formula), budgeting is far easier, and surprise bills are eliminated. This stability is particularly beneficial for CFOs and finance teams that require consistent forecasts.
- Simplified Management: TFP brings simplicity. Instead of constantly tuning and capping workloads to manage costs (a common headache under MLC), you can run your systems at optimal capacity without fear. Procurement and finance teams find it easier to model costs since the pricing model is straightforward and transparent. It reduces the administrative burden of tracking rolling 4-hour peaks and tweaking capacity just to control license fees.
- Potential Savings in Growth Scenarios: If your organization anticipates significant growth in mainframe workloads, TFP can secure pricing before that growth occurs. In a heavy-growth environment, this can lead to savings. For example, if you double your transaction volume, under MLC your costs might skyrocket; under a fixed TFP deal, you’re shielded from that sudden increase. In essence, IBM is taking on some risk of your growth in exchange for the committed fee.
- Bundled Flexibility (New Workloads): IBM often bundles in newer pricing models (like container pricing for specific workloads) as part of a TFP agreement. This means you may be eligible for flexible terms for hybrid cloud or new applications on Z. For instance, IBM offers specialized sub-models for development/test environments, as well as modern applications on Z. Under TFP, these can be included, so that modernizing your mainframe (e.g., adding new Java or AI workloads in a “container”) won’t increase your costs. It encourages innovation on the platform by removing the fear of cost for new projects.
Checklist: Before embracing TFP’s benefits, make sure you’ve done your homework:
☐ TFP model type chosen – Confirm whether you’ll use the Consumption or Capacity variant, based on which aligns with your environment.
☐ Cost modeled vs. past usage – Compare the proposed TFP fee against your actual costs over the last 3–5 years. Would TFP have saved money in those years, or would it have cost more? This historical check is crucial.
☐ Growth forecasts stress-tested – Run “what-if” scenarios on your growth. If workloads grow 20%, is TFP clearly cheaper than MLC? If workloads stay flat or dip, what happens? Ensure the TFP deal remains viable under various future scenarios.
Insights on licensing models, IBM Sub-Capacity Licensing on Mainframe vs Distributed: What’s the Difference?.
3. Risks of IBM TFP
TFP can be a game-changer, but it also comes with potential pitfalls. It’s essential to understand the risks so you’re not caught in a costly trap:
- Overpayment Risk: With a fixed or committed price, you risk overpaying if your workloads shrink or you optimize efficiency. Under TFP, you pay the agreed fee regardless of actual usage. So if your MSU consumption drops due to, say, moving some workloads off the mainframe or tuning your applications, you won’t see a corresponding drop in cost. In a traditional MLC model, reducing usage would save you money; under TFP, those savings are off the table until the contract period ends.
- Lock-In and Limited Flexibility: TFP contracts typically run for multiple years (often 3 to 5 years). This long commitment can create a lock-in effect. If business needs change or you find a better alternative, you can’t easily exit the TFP agreement without penalties. You’re essentially locked into IBM’s model for the duration, which can be risky if the organization’s direction or the tech landscape changes rapidly.
- Complex, Custom Deals: Ironically, while TFP simplifies billing, the contract itself can be complex. IBM negotiates TFP deals on a customer-by-customer basis, which means terms and conditions can vary widely. There isn’t a one-size-fits-all rate card. This complexity can hide gotchas – for example, how growth beyond a certain point is charged or how reductions are handled – which could be buried in the fine print. If you don’t thoroughly understand the terms, you might agree to conditions that favor IBM more than you.
- Loss of Leverage: When you move to TFP, you may sacrifice some negotiation leverage. In the traditional model, you could continually optimize or even threaten to reduce mainframe usage to keep costs down or negotiate better discounts. Once on a fixed subscription, IBM already has your committed spend. It can be difficult to revert to MLC later or renegotiate for a lower price mid-stream – you’ve given up the flexibility of pay-as-you-go, and IBM knows it. This loss of leverage can make future negotiations more challenging, as the baseline cost is locked in their favor.
Checklist: Before signing a TFP contract, address these risk factors:
☐ Model downturn scenarios – What if your transaction volume or MSU usage declines by 10%, 20%, or more? Calculate the cost impact under TFP vs. traditional pricing to see if you’d be overpaying.
☐ Negotiate exit options – Work with IBM to include an exit or reversion clause. Can you revert to MLC after a certain period, or are there provisions for termination if needed? Get any re-opener clauses in writing.
☐ Validate long-term forecasts – Be confident in your 3-5 year workload projections. If there’s uncertainty (mergers, cloud migrations, etc.), acknowledge that in the deal. Try to build in flexibility or, at the very least, avoid overcommitting to a volume that you can’t guarantee.
4. Negotiation Considerations
When approaching a Tailored Fit Pricing deal, negotiation is key. IBM will, of course, aim to structure the deal to its advantage (ensuring it secures as much of your IT budget as possible). As a savvy customer, you should approach TFP discussions strategically and skeptically.
Here are important negotiation tips and considerations:
- Benchmark Against History: Before anything, crunch the numbers. Calculate what you have been paying under MLC historically (including all the tuning and capping you’ve done to control costs). Compare this to IBM’s proposed TFP annual price. If, for example, you averaged $20M/year in MLC charges over the last few years (after optimizations) and IBM proposes a $25M/year TFP deal, ask why. Ensure the premium is justified (e.g., by future growth or added value). Don’t accept a TFP price blindly – it should be grounded in data.
- Re-Opener Clauses: Negotiate a mid-term review or re-opener clause. This means after a set period (say 2 years into a 5-year deal), you have the right to revisit the terms. If your business has changed or the deal isn’t delivering the expected value, you may be able to renegotiate the rate or even opt out without incurring heavy penalties. IBM might resist, but it’s a reasonable request to protect you from unforeseen changes.
- True-Down Rights: Just as cloud contracts sometimes offer “flex-down” provisions, push for true-down rights in your TFP contract. This would allow you to reduce your committed capacity or annual fee if your needs decrease (perhaps with some notice or minimal fee). It prevents a scenario where you’re paying for ghost workloads that no longer exist. Even if IBM doesn’t allow a full true-down, try to cap your downside – for instance, consider reducing your fee by 10% if year-over-year usage drops significantly.
- Don’t Surrender Existing Discounts Lightly: Many enterprises have spent years negotiating deep MLC discounts or advantageous agreements for certain software products. Be cautious about trading those away. IBM might promise simplicity or even a small short-term incentive to move to TFP, but if it means giving up a 30% MLC discount that you can’t get back, think twice. Ensure that the value of your current entitlements is factored into the TFP pricing. You don’t want to lose a hard-won discount for the sake of a new model that doesn’t truly save money.
- Leverage Your Commitment: IBM values predictable revenue, so it benefits when customers move to TFP. Use that to your advantage by asking for extras. This could include Technology Upgrade Credits (applied toward new hardware purchases), additional software licenses at no extra cost, complimentary training, or extended support periods. Essentially, sweeten the pot for yourself. If you’re going to give IBM a multi-year commitment, you should receive more than just a pat on the back – get tangible concessions that improve your mainframe environment or reduce other costs.
- Watch for Scope Creep: Clearly define what products and workloads the TFP deal encompasses. Sometimes IBM might bundle certain products in, but exclude others. Ensure all the mainframe software you use is covered, or know what isn’t. Anything left out will still incur charges outside the TFP agreement, which could undermine the predictability you’re seeking.
Approach the TFP negotiation like a long-term partnership discussion. Be skeptical but constructive – IBM reps will position TFP as a win-win, but it’s your job to ask the tough questions and ensure it’s truly a win for your organization, not just IBM.
5. Scenario Example
To illustrate the pros and cons of TFP, let’s look at a real-world style scenario:
Scenario: A large financial institution (BankCo) decided to move from traditional MLC to IBM’s Enterprise Consumption TFP model. They negotiated a fixed price of $25 million per year for all IBM Z software, based on their previous usage and growth forecasts.
The contract was for 5 years of coverage, guaranteeing IBM a steady $25M annually from this client.
- At first, it felt like a huge win. BankCo’s IT team no longer spends weekends worrying about monthly peak MSUs. They stopped implementing artificial caps that sometimes degraded performance just to avoid charges. With TFP, they ran their systems at full throttle during end-of-quarter processing, and the bill stayed at $25M. The CFO loved the predictability – budgeting for mainframe software was as easy as writing “$25,000,000” in each year’s budget, with no contingency needed for spikes. The operations team noticed improved system responsiveness because they could let workloads scale as needed, thereby improving the customer experience during high-traffic periods. In short, the first year under TFP eliminated cost surprises and significantly reduced internal cost-management efforts.
- However, mid-way through the contract, a twist occurred. BankCo undertook a digital transformation initiative, migrating some workloads from the mainframe to a cloud platform and optimizing others. The result: their mainframe MSU consumption decreased by about 10% in year 3. Under the old MLC model, a 10% drop in usage would have translated to roughly 10% lower software bills (saving a few million dollars). However, under the TFP deal, BankCo was still liable for the full $25M. That year, in effect, they overpaid relative to their actual usage. Finance started questioning if they had locked in too high a commitment. Had they stayed on MLC, their costs might have been closer to $22 million, given the reduced usage – meaning the TFP “safety net” cost them an additional $3 million that year.
Outcome:
Over the 5-year term, BankCo had both positive and negative experiences. In the growth years (the first two years, during which workloads increased slightly), TFP saved them money and headaches.
In the later years, when the mainframe footprint shrank, TFP became more expensive than pay-as-you-go would have been. The key lesson for BankCo was the importance of flexibility. They realized that while TFP protected them from spikes, it also locked them in. In hindsight, they wished they had negotiated a clause to adjust the annual fee if usage dropped beyond a certain threshold.
Lesson: TFP can be a game-changer in the right scenario, but it can turn into a cost trap if your situation changes. Organizations should learn from BankCo’s experience – structure TFP deals with provisions for change, and always keep an eye on actual usage versus what you’re paying. The scenario highlights why a one-size-fits-all approach can be detrimental over multiple years.
6. FAQs (Frequently Asked Questions)
Q: Will TFP save money for a stable mainframe workload?
A: Not always. If your workloads are stable or declining, a well-optimized MLC model might cost less over time. TFP shines for enterprises expecting significant growth or those who value cost predictability above all. Always benchmark TFP against your past 3–5 years of MSU usage to see if it truly saves money in your case.
Q: Can I go back to traditional pricing later if TFP doesn’t work out?
A: IBM rarely allows a clean switch back once you commit to TFP, at least not without financial pain. It usually requires tough negotiation and may involve penalties or the reversal of discounts. It’s safest to negotiate for a re-opener clause or an exit option upfront, just in case you need it after a couple of years.
Q: Does TFP eliminate the need for SCRT reporting and sub-capacity tracking?
A: No, you still have to run IBM’s Sub-Capacity Reporting Tool (SCRT) and provide monthly reports. TFP changes how you’re billed, but IBM uses those reports to ensure compliance and understand your usage. In other words, the homework isn’t gone – reporting remains, and mistakes in reporting can still carry audit risks. TFP is about billing simplicity, not about removing usage tracking.
Q: Is TFP always cheaper than MLC in the long run?
A: No. TFP can end up costing more if your workloads shrink or if you successfully implement optimization projects that lower usage. TFP is designed to give IBM predictable revenue. Customers should model multiple scenarios (growth, flat, decline) before agreeing to a multi-year TFP. In some cases, adhering to MLC with aggressive cost management can indeed be more cost-effective.
Q: Does TFP cover IBM’s container pricing and new workload models on Z?
A: Yes, typically, TFP agreements can bundle in container pricing models. IBM introduced special pricing for items such as development/test environments, as well as new applications (often referred to as “container” or “workload-based” pricing). Under TFP, these are usually included or can be negotiated, which is great if you plan to modernize and add new workloads to the mainframe. Just be sure to review those terms carefully – you want to avoid overcommitting to capacity for new workloads that you might not fully utilize. In short, TFP can cover these new models, but you’ll want to ensure you’re actually going to use what you’re paying for.
Read about our IBM Licensing Advisory Services
