The consumption models, when they beat monthly charges, and how to run the comparison honestly. Three knowledge checks along the way, and 4 clips from a senior licensing analyst.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. 4 times in the session the frame splits and a senior licensing analyst gives the view from inside real IBM negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome to session seventeen. Last time we established that the mainframe bill is set by a peak you can shape, and I ended by saying that a consumption model prices from your recent consumption, so moving before you have shaped the peak locks the unshaped number in. Today is that model in full. Tailored Fit Pricing replaces peak based charging with committed consumption and built in growth assumptions. It is presented as modernisation. It is a pricing decision. And modelled honestly on your actual profile, the answer is sometimes yes, often no, and always worth knowing before signing. Three knowledge checks. Let's begin.
Five objectives. First, name the models, which are a committed capacity band, a consumption model with a baseline plus metered growth, a development and test carve out, and ring fenced container pricing. Second, understand what a baseline does, because it grandfathers whatever consumption you bring to the table, which makes the choice of the twelve month window the entire negotiation. Third, sequence it correctly, meaning optimise first and sign second, because a baseline drawn from an unoptimised year has locked in around a third of overspend for the length of the term. Fourth, say honestly which estates it suits, because it rewards growth and penalises shrinkage, so a decommissioning estate is usually better off on a peak model it actually manages. And fifth, protect the technology dividend, because a baseline does not fall on its own at a hardware refresh.
Four numbers. Plus thirty three percent, the overspend locked in where a baseline was set from a peak twelve months rather than an optimised one. Ten to twenty percent, the avoidable cost carried by estates that signed without doing a baseline year analysis at all. Half, the share of estates that had never modelled the consumption option against their own actual profile before being asked to decide on it. And nought to ten percent, which is what the move itself is worth on price in the reduction matrix, and I want you to hold that number against the first one, because the model change is worth very little and the baseline you bring to it is worth a great deal. Then the note, which is as direct as I can make it. IBM presents it as modernisation because it usually pays IBM.
Guest analyst clip. I want to be careful here, because there is a lazy version of this argument that I do not hold. The lazy version says the vendor is offering it, therefore it is bad, refuse it. That is not analysis, it is reflex, and it will cost some organisations real money because for a genuine subset of estates this model is the right answer. What I would say instead is more specific. The model is presented as modernisation, in the language of cloud and consumption and flexibility, and that framing is doing persuasive work that the economics may or may not support. Modernisation is a word that makes a decision feel obvious. And the moment a commercial choice feels obvious, most organisations stop modelling it. So the discipline is simply to strip the framing off and ask the boring question: on my actual consumption profile, over a low year and a high year, does this cost more or less than the model I have, run properly. That question has an answer. It is knowable in advance, from data you already hold. And the striking thing is how many estates arrive at the decision having never asked it, which is how something ends up being sold on a feeling.
Strip the framing off and ask the boring question, because it has a knowable answer sitting in data you already hold. So, the models themselves.
Four shapes, and what each is really selling. Enterprise Capacity bills a committed capacity band with a growth allowance, suiting a flat workload where you value certainty, and the thing to watch is that it sets your current peak as a permanent floor. Software Consumption bills an annual baseline plus consumption at a reference rate, suiting predictable growth you can meter, and the thing to watch is that the baseline grandfathers whatever you bring. Development and Test prices non production workload at a deep discount, suiting estates that can isolate non production onto its own footprint. And Container Pricing rings fences a net new workload so it prices on its own terms rather than lifting the whole estate's peak, with scope creep as the thing to watch. Then the note. Enterprise Capacity buys certainty at the price of a higher floor, Software Consumption rewards metering and discipline, and predictability is worth paying for only once you know what you are fixing the price at.
Knowledge check one. You have not yet run a peak shaping programme. IBM offers a consumption model priced from your last twelve months. What is the risk? A, none, the baseline reflects reality and reality is the fairest basis. B, the baseline grandfathers your unshaped consumption, locking the overspend in for the term. C, only that the growth allowance may be too small. D, the model cannot be priced without a shaped peak. Pause here, and ask what exactly the last twelve months is a measurement of.
The answer is B. A baseline drawn from an unoptimised twelve months has locked in around a third of overspend, and customers who migrated first and optimised later handed every subsequent gain to IBM, because the price had already been fixed by the time they improved anything. Answer A is the reasonable sounding version of the mistake, and I want to take it seriously because the sentiment is fair. The baseline does reflect reality. The difficulty is which reality: the last twelve months is a measurement of your unmanaged workload rather than of your requirement, and those are different numbers, sometimes by twenty or thirty percent.
So, the baseline, five points. It sets a price per unit from your prior consumption and then runs it forward with a contracted growth band, which means the window chosen decides the rate you live with for years rather than for a quarter. Choose the window after optimisation rather than the window proposed by default, so you run the reduction programme, let consumption settle for a full quarter, and only then fix the baseline. Beware the atypical year, because a window measured during a peak season, a migration or a quarter end heavy period locks a higher price into a multi year contract for reasons that will have stopped being true. Model a low year and a high year, because the honest comparison is a range rather than a point, and the range is what tells you whether certainty is worth its premium. And forecast before you fix it, modelling peak workload, batch windows and new application onboarding beforehand rather than discovering them inside a band that is already set.
Now the grandfather effect, which is the heart of this session. Every gain before signature is yours, because peak shaping, capping and offload all lower the consumption the baseline is drawn from, so they reduce the price per unit you carry forward. Every gain after signature is theirs, because the same work done a month later reduces consumption against a price that has already been fixed, which changes who benefits entirely. The measured gap is the prize, since billed usage ran twenty to thirty five percent above sustained workload before tuning, and that gap is exactly what a baseline would otherwise grandfather. A worked shape makes it concrete, where a two thousand six hundred unit billed peak resolves into one thousand seven hundred and fifty sustained, three hundred and fifty of burst buffer and five hundred reclaimable, which puts the honest baseline target at two thousand one hundred rather than two thousand six hundred. So the sequence is not a preference, it is the difference between two prices for the same estate.
Guest analyst clip. Optimise first, sign second. Four words, and in my experience they are worth more than everything else I could tell you about this model combined. Let me put the mechanism in the plainest terms I can. Whatever you do to reduce consumption before the baseline is set, you keep, because it lowers the number the price is calculated from. Whatever you do afterwards, you have donated, because consumption falls against a price that is already fixed. Same work, same engineers, same result on the machine. Entirely different beneficiary, decided purely by which side of a signature it happened on. Now here is why this goes wrong in practice, and it is not stupidity. Signing is a date in a calendar controlled by a commercial process, and optimising is a project that needs engineering time nobody has allocated. So the signature arrives first because signatures always arrive first. What I ask organisations to do, therefore, is not to optimise faster. It is to move the date. Start the reduction programme a hundred and eighty days before the decision, so the two sequences overlap in the right order. That is a scheduling decision made by one person in one meeting, and it is worth more than any clause in the contract.
Move the date rather than trying to optimise faster. A hundred and eighty days out, so the two sequences overlap in the right order.
Knowledge check two. Your estate is shrinking as applications move off the platform. Which model suits you? A, the consumption model, because a shrinking estate consumes less and will bill less. B, the peak model, actively managed, because a baseline locks last year's higher consumption while a peak model lets each reduction lower the bill. C, Enterprise Capacity, for the certainty during a transition. D, either, the models converge over a three year term. Pause here, and ask in which model a reduction you make actually reaches your invoice.
The answer is B, the peak model, actively managed. Consumption pricing rewards growth and sub capacity peak pricing rewards shrinkage, so a decommissioning estate is penalised by a baseline that fixes last year's number. Answer C is the most tempting wrong answer here, and it deserves a proper hearing, because a transition genuinely is an uncertain period and certainty genuinely is valuable during one. The difficulty is what you are buying certainty about. A committed band during a period when your consumption is deliberately falling means paying a fixed amount for capacity you are actively in the process of removing, which is certainty pointed in precisely the wrong direction.
So who does it suit, honestly. Growing estates with genuinely uncontrolled peaks, where the peak model punishes a workload shape you cannot realistically manage, and removing the peak penalty is then worth real money. Flat or shrinking estates, usually not, because each year's reduction should be lowering the bill and a baseline stops that happening while charging you for the privilege. Peaky but manageable, cap instead, and this is the distinction that decides most cases, because the question is not whether your peaks are spiky, it is whether anybody is managing them. New workloads, ring fence them, because container pricing prices a net new application on its own terms rather than lifting the whole estate's peak, and that is a genuinely useful shape. And model it before you are asked, because one benchmark estate found the consumption model priced higher than well managed monthly charges, and retained the old model on the evidence.
Guest analyst clip. The distinction I would hold onto is between peaky and unmanageable, because they get conflated constantly and they lead to opposite decisions. A peaky workload is one whose usage varies a lot across the month. That describes almost every mainframe estate on earth, and on its own it tells you nothing about which pricing model to take. An unmanageable workload is one where the peaks cannot be moved, capped or offloaded, because of genuine business or regulatory constraints. That is a much rarer thing, and it is the actual case for consumption pricing, because if you truly cannot shape the peak then being billed on it is a penalty you cannot avoid and paying a different way makes sense. So the honest test is a question about your organisation rather than your workload. Have we tried. Have we identified the peak makers, looked at what they are, and established that they genuinely cannot move. In my experience, most estates that describe themselves as unmanageable have never run that exercise, and a meaningful proportion of them discover, when they do, that a single batch window could be shifted by two hours with nobody objecting. That estate does not need a new pricing model. It needs a scheduling change and the old one.
Peaky is not the same as unmanageable, and the test is whether you have actually tried. Now, the thing that happens after you sign, at the next refresh.
The technology dividend, and what happens at the next hardware refresh. A refresh normally lowers the count, because newer machines do the same work for fewer units, and on a peak model that improvement lands in your column automatically without anybody negotiating anything. A fixed baseline does not fall on its own, so the same refresh under a signed baseline produces an improvement that goes to the vendor rather than to you. Make it one negotiation, so the refresh and the baseline reset sit in the same conversation and the dividend gets allocated deliberately rather than by default. The effect is large, with an effective rate that stays flat at a locked baseline against one that falls substantially where the refresh and the reset were negotiated together. And it compounds with the sequencing point, because if you optimise before signing and then reset at refresh you keep both improvements, while missing both means handing over two separate gains that you paid to create.
So, five protections to write into the schedule. The baseline grandfather stated explicitly, covering what consumption the baseline reflects and from which window, so the number is documented rather than assumed by two parties who remember it differently. The growth allowance matched to your roadmap, so organic growth is pre priced rather than re quoted mid term when you have no leverage. A true down right, because without one a drop in use never reduces the bill, so you pay for growth you had and keep paying after it ends. The right to revert or stay, a written protection allowing you to remain on or return to the peak model if the workload shrinks, which keeps the dividend on your side of the table. And the technology dividend at refresh, written down before the refresh happens, because afterwards the improvement has already been allocated and the argument becomes retrospective, which is the weakest kind.
Knowledge check three. How should the comparison between the two models actually be run? A, compare the vendor's consumption quote against your current bill. B, compare the consumption quote against a properly shaped peak model, over a low year and a high year. C, take the model with the lower headline rate per unit. D, ask IBM to model both, since they hold the pricing data. Pause here, and ask what the right comparator is: what you pay today, or what you could pay today.
The answer is B. Comparing against your current unmanaged bill flatters the new model by exactly the amount of waste you have not yet removed, which is why answer A is both the comparison that usually gets run and the one that misleads. And notice it is not a dishonest comparison, which is what makes it durable. Your current bill is a real number, it is what you are paying, and a model that beats it does look better. The right comparator is the best version of the model you already have, tested across a low year and a high year, because the honest question is not whether this beats your worst self.
Guest analyst clip. Compare against the best version of what you already have. That principle is not really about mainframe pricing at all, and I think it is the most transferable idea in this module. Whenever a vendor proposes replacing something, the comparison that gets drawn is between their proposal and your current state. And your current state contains all of your accumulated neglect: the workload nobody shaped, the tools nobody retired, the entitlement nobody reconciled. So the new thing wins, and it wins by the size of your neglect rather than by any merit of its own. What you should be comparing against is the version of your existing arrangement that you could have within a quarter if somebody paid attention to it. Sometimes the new model still wins on that basis, and then you take it with real confidence, knowing what you are buying. Quite often it does not, and you have saved yourself a multi year commitment. Either way you now know something about your own estate that you did not know before, and that knowledge does not expire when the proposal does. I have never seen an organisation regret doing the comparison properly, including the ones who went ahead and signed.
So, how to run the comparison without fooling yourself, five steps. Shape the peak first and then wait a quarter, letting consumption settle so the baseline reflects the estate you actually run rather than the one you happened to have during a busy season. Build both models on three years of history, because your own submission history is the honest input, and it is data you already hold and did not have to ask anybody for. Test a low year and a high year, since certainty has a price and you can only judge it once you know the range it is protecting you against. Start a hundred and eighty days out, so the reduction programme and the negotiation are one sequence and the deadline works for you rather than against you. And be willing to stay, because one benchmark estate modelled it properly and kept the peak model, which is a perfectly good outcome and one only available to people who ran the numbers.
Three sentences. Tailored Fit Pricing replaces peak charging with a committed band or a baseline plus metered growth, and whichever shape you take, the baseline grandfathers whatever consumption you bring to the table, which makes the choice of the twelve month window the whole negotiation. A baseline set from an unoptimised year has locked in around a third of overspend for the term, so the sequence is optimise first and sign second, and the same gains made a month after signature accrue to IBM rather than to you. And it rewards growth and penalises shrinkage, one benchmark estate found it priced higher than well managed monthly charges and stayed where it was, and the honest comparison is against a properly shaped peak model across a low year and a high year rather than against the unmanaged bill you happen to be paying today.
Homework, about an hour. Pull three years of submissions, because that history is both your baseline evidence and your modelling input, and it belongs to you rather than to whoever is proposing a model. Split your billed peak into three parts, sustained workload, burst buffer and reclaimable, because that third number is exactly what a baseline would grandfather if you signed today. Ask which direction the estate is going over the next three years, growing, flat or shrinking, because that single answer eliminates one of the two models immediately and saves you a great deal of modelling. Find the next hardware refresh date and ask whether it falls inside the term you are being asked to sign, because if it does then the technology dividend is on the table whether anybody names it or not. And check the calendar, asking whether you are a hundred and eighty days from the decision, because if you are not, the sequence that produces a good outcome may not fit, and that is worth knowing now rather than later.
Five guides. The mainframe optimization page explains why the consumption model is presented as modernisation and what an honest model of your own profile actually shows. The CIO advisory covers which estates it helps and which it hurts, the baseline year analysis, and modelling a low year against a high year. And the MLC and IPLA negotiation guide sets the model options side by side, with the line about predictability being worth paying for only once you know what you are fixing the price at.
The optimization guide treats the baseline as the risk, and explains why a window measured in an atypical season locks higher cost for the whole term. And the banking guide covers container pricing for new workloads, and how many estates had never modelled the consumption option against their own profile before deciding. Next time, the IBM audit: triggers, the third party auditors, the scope letter, and the first five moves that decide the outcome. See you there.