(If you haven’t read my first two blogs in this series on sub-capacity MLC pricing and controlling MLC with capping, I recommend you read those first.)
Tailored Fit Pricing is arguably the most significant software pricing announcement from IBM in over ten years.
This year IBM announced Tailored Fit Pricing. Tailored Fit Pricing is arguably the most significant software pricing announcement from IBM in over ten years. At a glance, the offering is ‘simple, flexible and predictable cloud-like pricing’. Having reviewed the details of the offering, I agree it appears to be all of these things. What I’m not convinced about, is whether this new offering will save your business money.
While there are sub-components within the Tailored Fit Pricing offering, this blog will focus on the ‘Software Consumption Solution’ (Previously called ‘Enterprise Consumption Solution’) as we expect this to be the option most datacenters consider.
Getting started with Tailored Fit Pricing, Software Consumption
Tailored Fit Pricing’s Software Consumption solution starts with a ‘baseline’ of existing consumption. IBM will ask for your last 12 months of SCRT reports. From this data, they will calculate a price per MSU by considering your accumulated MSU consumption for the past year as well as the total of your MLC charges.
The new TFP Software Consumption contract is long term (e.g. 3 years) with annual “committed MSU’s” derived from your baseline. Supporting the ‘predictable’ aspect, your new monthly charges should be 1/12 of the annual commitment. Unused MSU’s at the end of the year may be carried forward to the following year. If still unused, at the end of the contract, they are forfeited. Going over your annual commitment will be invoiced at a ‘discounted rate’.
Of course, all of these details can be negotiated so make sure you have your best contract people involved up front.
The key difference with TFP’s Software Consumption solution vs existing software models is the chosen measurement metric. Existing models use the Rolling Four-Hour Average (R4HA) while Software Consumption uses total MSU consumption, calculated from Effective Dispatch Time (EDT).
EDT is a very precise measurement expressing the amount of time an LPAR received effective access to the physical CPU hardware in a CEC. MSU (Millions of Service Units) is a less granular value created for the express purpose of software pricing. IBM provides an MSU rating for each make/model of machine (published in the Large Systems Performance Reference: LSPR).
Let’s take a drive
A clearer way of contrasting the two methods is driving a car. The R4HA is a measurement of your average speed, over four hours; Software Consumption measures precisely how far you drove.
It has been previously suggested that a capping method could help with TFP’s Software Consumption; I don’t see how. Caps reduce consumption rate but not absolute value. A program that needs 10 minutes of CPU still needs 10 minutes of CPU. Capping might make the job run twice as long but it still consumes the same amount of CPU time.
Using the car analogy, a cap may be employed to control your average speed (R4HA) but the distance travelled remains fixed (it just may take you longer to get there). As Software Consumption billing is based on the distance travelled (accumulated consumption), caps cannot help.
zIIP is good
It’s already well established that workloads running on zIIP reduce costs. CPU consumption on zIIP is completely excluded from MLC charges in both the new and old models. A difference with Software Consumption involves timing.
Under existing (R4HA) models, if zIIP-eligible work ‘crosses over’ to a general-purpose processor (GP), that may contribute to your software bill. It depends if that crossover occurred during a R4HA peak; if not, it doesn’t matter. In contrast, every GP CPU second – regardless when it occurs – contributes to total consumption, thus contributing to the Software Consumption allotment.
…consider if your consumption is growing. If not, Tailored Fit Pricing’s Software Consumption Solution is probably not right for your business.
Regardless of your chosen billing method you should aggressively pursue reducing your current R4HA software expense. On existing models, this reduces costs immediately; if Software Consumption is in your future, this reduces your baseline – which is a commitment that never goes down. In this light, consider if your consumption is growing. If not, Tailored Fit Pricing’s Software Consumption is probably not right for your business.
In any case, there are many other details not covered here and it is critical to understand how your costs are calculated today. IntelliMagic Vision is the most comprehensive solution on the market to gain insight into these details. Regardless of which model you select, ensure your decisions are based on accurate data.
This article's author
Senior z/OS Consultant
More from John
Share this blog
How to use Processor Cache Optimization to Reduce z Systems Costs
Optimizing processor cache can significantly reduce CPU consumption, and thus z Systems software costs, for your workload on modern z Systems processors.
Mainframe Cost Savings Part 2: 4HRA, zIIP Overflow, XCF, and Db2 Memory
This blog covers several CPU reduction areas, including, moving work outside the monthly peak R4HA interval, reducing zIIP overflow, reducing XCF volumes, and leveraging Db2 memory to reduce I/Os.
Mainframe Cost Savings: Infrastructure Opportunities Part 1: Processor Cache
CPU optimization opportunities applicable across the infrastructure can often by implemented without the involvement of application teams and can benefit a significant portion (or all) of the work across the system.
Don’t Keep Your CPU Waiting: Speed Reading for Machines | IntelliMagic zAcademy
This webinar discusses the many tiers of storage in IT systems and offers ideas about how to optimize access to those areas.