The bundles, the Virtual Processor Core metric, and the entitlement conversion ratios that decide what you actually get. 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 eleven, and to module three, which is the modern estate. Everything in module two counted physical things, cores in machines and machines in clusters. Cloud Paks count something different, and they change the shape of the question. A Cloud Pak is IBM middleware packaged as containers on OpenShift, licensed against one pooled metric, and the flexibility of that pool is genuinely the product. It is also what IBM charges you for, whether or not you use it. So today is about counting the pool, reading the ratios, and knowing what the premium is actually buying. Three knowledge checks. Let's begin.
Five objectives. First, count a Virtual Processor Core, because the metric counts the running container rather than the host, so a container with a four core limit is four VPC, and non production usually runs at half rate. Second, read a conversion ratio, because WebSphere ND converts at roughly one VPC per two hundred and eighty PVU while Db2 Advanced converts at one per two hundred and forty, and a single headline ratio flatters the whole estate at once. Third, model the draw down rather than the core count, since components consume the pool at different rates and App Connect can deploy on thirty cores and take ninety tokens from a two hundred token pool. Fourth, price the bundle honestly, because below three components standalone is usually cheaper and at three or more the premium starts to repay through fungibility. And fifth, find the OpenShift entitlement, because most Paks carry restricted OpenShift at roughly three to one, and about half of estates paid for it twice.
Four numbers. Thirty two percent, the median share of entitled cores with no running workload mapped to them, and support is paid on all of it every year. Three of four, the Cloud Pak proposals rebuilt where the buyer had over committed by twenty two to forty one percent against trailing deployment data. One in three, the estates where swap rights went unused, leaving paid entitlement stranded inside a single product. And three to one, the restricted OpenShift entitlement most Paks carry, at roughly three VPC of OpenShift per one VPC of Pak. Then the note, which is the sentence that reorders most negotiations. The bundle discount is real and it is the smallest lever on the table. The two that move the bill are the conversion ratios and the measurement discipline.
Guest analyst clip. The way I explain a Cloud Pak to a board is that you are buying a key to every room in a building, and then paying rent on the rooms you never enter. And people usually smile at that, and then somebody asks the obvious question, which is whether that is a bad deal. It is not, necessarily. If you are going to walk through most of those rooms over the next three years, the key is excellent value and the alternative of buying each door separately is worse. The problem is that almost nobody checks afterwards which doors ever opened. The median estate we look at holds about a third of its entitlement against nothing at all, and has been paying support on that third every year since signature. Now what strikes me is how easily that is fixed, because it does not require a negotiation or a lawyer. It requires somebody to list the components in the Pak and put a yes or a no next to each one. An afternoon. And that list, honestly produced, is simultaneously the answer to how much you are wasting, the agenda for your next renewal, and the reason your renewal quote should be smaller rather than larger.
A list of components with a yes or a no next to each. An afternoon's work, and it is your waste number and your renewal agenda at the same time. So let us start with how the metric counts.
Four rules for counting a Virtual Processor Core. It is counted at the container, so a container with a four core limit counts as four VPC, and the host and the worker node are not the unit, the running container is. It is capped by the physical, so if virtual cores exceed physical cores you license the physical, which means over allocation stops helping you and starts costing you. Non production runs at half rate, with most products at nought point five VPC per virtual core outside production, so test estates are cheaper than people assume but they are not free. And workers only, since master and infrastructure nodes are excluded from the count, right up until an application workload is scheduled onto them, and then they are not. The note underneath is the arithmetic worked through. One hundred containers at four cores each in production is four hundred VPC. A non production replica at the same scale adds two hundred. The entitlement runs at six hundred.
Knowledge check one. Your team deploys Cloud Pak containers with no CPU limits set, on nodes with plenty of headroom. What is the licensing effect? A, none, because the containers only use what they need. B, the count follows what is assignable, so an unlimited assignment bills the node rather than the workload. C, the count defaults to one VPC per container. D, the count is averaged across the quarter. Pause here, and ask whether the metric bills consumption or assignment.
The answer is B. On container platforms without resource limits set, VPC counts came in twenty to forty percent above the equivalent PVU footprint, because the metric bills the assignment. Answer A is the consumption assumption in its newest costume, and I point that out deliberately, because this is the third session in a row where it has been the wrong answer. Utilisation was not a defence on PVU, averages were not boundaries on Power, and consumption is not the count here either. What is genuinely new is the fix. Setting container resource limits is a licensing control now, not a platform hygiene item, and it is a one line change in a manifest.
So, the bundles themselves. Integration holds MQ, App Connect, API Connect, DataPower, Event Streams and Aspera, with typical estates running two hundred to eight hundred VPC. Data holds Db2, Watson Studio, Knowledge Catalog, DataStage and Cognos, and typical estates run three hundred to fifteen hundred VPC, the largest of the family. Business Automation, AIOps and Security hold workflow and decision management, Instana and Turbonomic, and QRadar and Guardium respectively, each typically two hundred to a thousand VPC. The pool is fungible inside the Pak, so a VPC held against Integration can run MQ this quarter and App Connect next with no repurchase, and that is precisely the thing you are paying a premium for. And swap rights stop at the boundary, running inside a Pak and never across Paks, so Integration components swap into each other and never into Data.
Now the ratios, which decide what your existing estate is actually worth. WebSphere ND, MQ Advanced and DataPower convert at roughly one VPC per two hundred and eighty PVU, so a fourteen thousand PVU WebSphere estate converts to about fifty VPC, and that is a number you can check yourself on a calculator. Db2 Advanced converts at roughly one VPC per two hundred and forty PVU, a better rate, which is why it is usually the product to lead a conversion with. Some products convert badly, because ratios vary by product and several are inflationary, so a conversion that reads clean in total can hide a double digit effective increase inside it. User based products have no published rate, so Cognos and similar convert by negotiation, which means the number is whatever you agree and it is worth modelling before the meeting rather than during it. And the headline ratio is the trap, because one flattering rate applied to the whole estate at once is exactly the number you should never negotiate against.
Guest analyst clip. The headline ratio is the most effective sales device I have encountered in IBM licensing, and I say that with a certain professional admiration, because it is not dishonest. It is simply an average, presented at the moment an average is most flattering. Here is how it works in a room. Somebody puts up a single conversion rate and applies it to your total PVU estate, and the resulting VPC number looks like a good deal, and it genuinely is a good deal for some of what is in that total. What the single rate hides is that your estate is a mixture. Some products convert generously. Some convert at parity. And one or two convert so badly that they eat the gains from everything else. Presented individually, you would push back on those. Presented as one blended number, there is nothing to push back on, because the average is arithmetically correct. So the discipline is unglamorous and it is decisive: do not accept a total. Ask for the rate per product, put your own volumes against each one, and add it up yourself. I have seen that exercise turn a conversion that looked like a fifteen percent saving into one that was a fifteen percent increase, and the only thing that changed was the order of operations.
Do not accept a total. Ask for the rate per product, put your own volumes against each, and add it up yourself. Which brings us to how the pool actually drains.
Knowledge check two. You hold a two hundred VPC Integration pool. You deploy MQ on one hundred cores at a two to one ratio, and App Connect on thirty cores at a one to three ratio. What have you consumed? A, one hundred and thirty VPC, because that is the core count deployed. B, one hundred and forty VPC, where MQ draws fifty and App Connect draws ninety. C, sixty five VPC, because both ratios reduce the count. D, two hundred VPC, because the pool is consumed in full once used. Pause here, and ask whether the ratios all run in the same direction.
The answer is B, one hundred and forty. MQ at two to one turns one hundred deployed cores into fifty tokens, and App Connect at one to three turns thirty deployed cores into ninety. Answer A is how almost every team budgets a pool, by core count, and it is exactly why they run out of tokens long before they run out of need. And look at which component is the expensive one, because it is counterintuitive. The smallest deployment took nearly half the pool. Thirty cores of App Connect cost you more entitlement than one hundred cores of MQ, and nothing about the size of those deployments would tell you that.
So the pool is a currency and the exchange rate varies by component. Every component has its own rate, some drawing less than the cores they run on and some drawing several times more, and that rate lives in the License Information document rather than in the proposal. Budget in tokens and never in cores, because a plan built on core counts is a plan built on the wrong unit and it will be wrong by a multiple rather than by a margin. Model the roadmap and not just today, since the component you intend to adopt next year may be the one that empties the pool, and that is knowable now for the price of reading a table. Check the ratio is in the order document, because ratios that live only in a slide are ratios that can move, while written into the order they are something you can hold IBM to. And re model at every anniversary, because consumption shifts as teams adopt components and the pool that fitted at signature rarely fits at renewal.
Guest analyst clip. There is an organisational failure hiding behind the draw down problem that I think is worth naming, because fixing the arithmetic does not fix it. The pool is bought by procurement, at a moment in time, based on a plan. The pool is then spent by half a dozen engineering teams, continuously, none of whom were in that meeting and most of whom have no idea a pool exists. They deploy a component because it solves their problem, which is correct, and each deployment silently draws tokens at a rate nobody told them about. So you have a shared budget with no visible balance and no spending controls, which is a situation you would never tolerate in any other part of the business. Imagine a company credit card that six teams could use, where nobody sees the statement until the year end. What I recommend is deliberately mundane. Publish the balance. Whatever your internal wiki is, put a page on it that says: here is the pool, here is what each component costs in tokens per core, and here is what is left. Update it quarterly. The teams are not trying to overspend, they simply cannot see the meter, and people behave completely differently once they can.
A shared budget with no visible balance. Publish the meter, update it quarterly, and the behaviour changes without anybody being asked to change it.
Now the OpenShift entitlement that arrives with the Pak, five points. Most Paks carry restricted OpenShift at roughly three VPC of OpenShift per one VPC of Pak, so a hundred VPC Pak brings about three hundred VPC of restricted OpenShift with it. Restricted means restricted, so it covers the Cloud Pak workloads, and your own applications on the same platform need their own subscription, which is session thirteen's territory. About half of estates paid twice, separately licensing the embedded entitlement because nobody mapped what the Pak already included against what was being renewed. Mixed clusters need documented separation, because without it the exposure defaults to the whole cluster rather than to the workloads that carry the entitlement. And one Pak is the exception, since Cloud Pak for Applications does not carry the restricted OpenShift entitlement, so this is a check rather than an assumption.
So where does Cloud Pak money actually go missing. Entitlement bought for a roadmap that never happened, where twenty to forty percent of entitled cores supported capabilities the estate never deployed, and in roughly two thirds of estates those capabilities never arrived at all. Pools sized to the cluster rather than to the containers, where between thirty and fifty percent of purchased tokens sat idle because the count ran against host cores instead of the container limit. Conversions accepted without checking the ratio, which has cost ten to twenty percent of paid entitlement value, quietly, at the moment of transition. Swap rights never exercised, unused on one in three estates, so entitlement sat stranded in one product while another was bought separately. And no true down right at the anniversary, because pools default to a floor at the committed level, which means without a true down you cannot shrink when a workload retires.
Knowledge check three. You use two components of a Cloud Pak family and have no plans for more. What does the economics say? A, take the bundle, because the headline discount beats standalone pricing. B, standalone per product is usually cheaper below three components, because fungibility is what the premium buys. C, take the bundle, because it is the only way to run on OpenShift. D, it makes no difference, the metrics are equivalent. Pause here, and ask what the premium is actually paying for, and whether you will use it.
The answer is B. At three or more components the bundle premium starts to repay itself through reuse, and below that you are buying access to rooms you will not enter. Answer A deserves a fair hearing, because the bundle is genuinely sold as thirty to fifty percent cheaper than the same products standalone, and that claim is true. It is also not decisive, and the reason is subtle. The comparison is priced against list, for capability you may never deploy. A discount on something you do not need is not a saving, it is a smaller version of a purchase you should not have made.
Guest analyst clip. The three component rule is the most useful thing I can give you on Cloud Paks, so let me be precise about how to use it, because it is a test rather than a law. The question is not how many components the Pak contains, and it is not how many you can imagine using. It is how many you will genuinely have in production within the term you are signing. And the honest answer to that is usually lower than the answer given in the room, because roadmaps are optimistic and roadmaps are what people quote. So I ask it a specific way. I ask what is funded. Not what is planned, not what is on a slide, but which of these components has a project with a budget and a name attached to it today. If that number is one or two, standalone pricing is very likely your answer and you should model it properly rather than assuming the bundle wins. If it is three or four with real funding behind them, the fungibility is worth having and the premium is doing something. What I want to protect you from is the middle case, where a Pak is bought on the strength of intentions, and then three years later somebody produces a capability map and discovers that a third of the entitlement never had anything running on it at all.
So, buying one well and running it well afterwards. Build a capability map first, listing which components are deployed, which are planned and which have never been opened, because that map is the whole negotiation in one page. Size to measured consumption plus your own headroom, not to the peak a vendor would quote you and not to the cluster, since trailing deployment data is the honest starting point. Get the ratios and a true down into the order document, meaning conversion ratios, component substitution and the right to shrink at the anniversary, because slides are not commitments. Retire what the Pak already covers, so standalone renewals for products now inside the bundle and separate OpenShift subscriptions the Pak already entitles. And review consumption quarterly, because the same reporting that proves your position also exposes the over commitment you can act on, which makes it the rare control that pays in both directions.
Three sentences. A Cloud Pak is IBM middleware packaged as containers on OpenShift against one pooled metric, where a Virtual Processor Core counts the running container rather than the host, non production usually runs at half rate, and an unlimited container assignment bills the node instead of the workload. The conversion ratios rather than the discount decide what you get, with WebSphere ND at roughly one VPC per two hundred and eighty PVU and Db2 Advanced at one per two hundred and forty, and components draw the pool at their own rates, so App Connect on thirty cores can take ninety tokens from a two hundred token pool while MQ on one hundred cores takes fifty. And the median estate holds thirty two percent of its entitlement against nothing at all and pays support on it every year, so the work is a capability map, sizing to measured consumption, and getting the ratios and a true down into the order document rather than into a slide.
Homework, about an hour. List the components you actually run, so for any Cloud Pak you own, which components have ever been deployed, and the ones nobody can name are the rooms you are paying rent on. Find one conversion ratio, by opening the License Information document for your Pak and finding the draw down rate for a single component, then comparing it to what the team assumed it was. Check for a double paid OpenShift subscription, asking whether the Pak entitles OpenShift and whether you are also renewing a standalone subscription on the same nodes. Count your idle entitlement, purchased VPC against VPC with a workload mapped to it, because the difference is your shelfware and you are paying support on it. And check for a true down right, by reading the order document, because if there is no right to reduce at the anniversary then your pool has a floor and only one direction of travel.
Five guides. The Cloud Pak licensing guide carries the capability map, the median thirty two percent of entitlement with nothing mapped to it, and what a renewal review actually recovers. The VPC licensing overview covers the metric itself, how allocation drives the count, and where the OpenShift cost gets quietly left out of the business case. And the Cloud Pak strategy guide sets out the counting rules at the container layer, the six Paks with their typical sizes, and how swap rights work inside a family.
The Cloud Pak strategy page carries the conversion ratio table from the legacy metrics, which is the one to model against before any transition conversation. And the negotiation guide covers entitlement overhang, the levers that actually move a Cloud Pak renewal, and how container limits change the licensable count. Next time, licensing in OpenShift and Kubernetes: the IBM License Service, and what changes when ILMT stops being the tool that measures you. See you there.