Anypoint Platform, the capacity model, and how integration spend scales with the estate. 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 SAP 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 back. Session sixteen, MuleSoft, and this opens module four on the wider portfolio. For fifteen sessions we have counted people, rows and conversations. Today the unit changes again, and this time nobody in your organisation is a user of the thing you are buying. You are buying compute capacity to run interfaces. So today: what capacity actually means and why it is set at design time, the four lines on the order form, where the sizing number comes from, the five places capacity sits idle, the bundle and the unlimited style agreement, and why this line grows every time you buy something else entirely. Three knowledge checks. Let's begin.
Five objectives. First, name the unit: capacity, expressed in cores, with nothing to do with how many people use it. Second, read a capacity sizing, meaning environments, redundancy and headroom, which is where most of the number comes from. Third, find the idle capacity, typically non production environments sized like production, running all year and used in bursts. Fourth, judge a bundle honestly, because integration inside a wider agreement is convenient and convenience has a renewal price. And fifth, explain the growth curve, because integration spend rises with every other cloud you buy and nobody forecasts for that.
So, the unit is capacity. Four things follow. Cores rather than seats: capacity to run integrations, sized in units of compute, bought annually. Deploy time cost, because the bill is set when architects choose an environment topology rather than at runtime. Idle still bills, since reserved capacity costs the same whether an interface runs hourly or never. And it grows sideways, because every new cloud you buy needs integrating, so this line follows all the others. Let me explain why that first point makes MuleSoft the clearest case of a problem we have been circling all course.
Guest analyst clip.
Designed by engineers and paid for by you, with the design decision made long before the invoice. That is the pattern, and MuleSoft is simply the purest example of it in the portfolio, which is why it is worth studying even if your own integration platform is something else entirely.
Right, four things on the order form. Core capacity: the compute your integrations run on, sized in cores, moved by environment count, redundancy and headroom far more than by traffic. Environments: production and non production, each consuming capacity, moved by how many stages your delivery process insists on. Edition or tier: which platform capabilities are included at your level, covering governance, security and management features you may already need. And add on capabilities: API management, monitoring and specialist connectors, usually discovered during delivery rather than at purchase. The order form looks short, which is misleading. Almost all of the money is in the first two lines, and both are set by an architecture decision rather than a commercial one.
First knowledge check. What drives MuleSoft cost most strongly? A, the number of people who use the integrations. B, the volume of messages processed. C, the environment topology and the capacity reserved for it. D, the number of systems you connect to. Pause here and pick an answer before you continue.
C. Reserved capacity is paid for whether or not anything flows through it, so the count of environments and the redundancy applied to each is the number that sets the bill. A is the seat instinct and it is simply not the model here. B feels right, and it matters only when volume forces you to add capacity, which is less often than architects assume. And D affects effort and connector requirements rather than the core line, because a hundred small interfaces can share the capacity that one badly sized environment wastes.
So where does the sizing number come from. It starts with peak rather than average, which is correct and rarely revisited afterwards. Then multiply by environments: development, test, staging, production, each consuming from the same pool. Then add redundancy, because high availability doubles the production figure and is often applied below production too. Then add headroom, a growth allowance on top, chosen by somebody who will not see the invoice. And then nobody revisits it, because the sizing is a launch artefact and the estate it described changed two years ago. Every step there is defensible on its own, and the compounding is what produces a number nobody can explain three years later. Now, where the waste actually sits.
Guest analyst clip.
Five places, then. Non production sized like production, so a test environment with production redundancy exercised two days a month. Environments nobody retired, meaning a staging tier from a programme that finished, still reserved and still billed. And headroom that never got used, growth capacity bought for a volume increase that did not arrive.
Then retired interfaces still deployed, holding capacity for a system decommissioned last year. And redundancy below production, where high availability is applied to environments in which an outage costs nothing at all beyond a developer waiting twenty minutes.
Second knowledge check. Your non production environments hold forty percent of total capacity. What is the first question? A, can we negotiate a discount on non production capacity. B, how often is each one actually exercised, and does it need production redundancy. C, can we move non production to a cheaper cloud region. D, should we consolidate to a single vendor for integration. Pause here before you continue.
B. Forty percent in non production is common and it is not automatically wrong, so the useful question separates the environments that earn their capacity from the ones copied off the production template and never questioned. A discounts something you may not need, which is the second best outcome available to you. C is an infrastructure question that rarely changes a capacity based licence. And D is a strategy conversation, and a very expensive way to avoid asking how often a test environment gets used.
Now the bundle, and the unlimited style agreement. Integration inside the wider deal means MuleSoft folded into a Salesforce agreement and priced as part of a larger commitment. The unlimited style agreement lets you deploy freely for a term in exchange for a fixed and usually rising annual fee. It removes friction, which is genuinely valuable while you are building and is the whole selling point. And it removes visibility, because nobody counts capacity during an unlimited term, so nobody knows what you use. Let me be specific about how that ends.
Guest analyst clip.
So the exit is the negotiation, not the entry. And that reframes what you should be doing during the term, which is not enjoying the freedom, or not only that, but quietly keeping your own count of what the freedom is producing.
Which brings me to why this line grows with everything else. Every cloud needs connecting, so marketing, commerce, service and data each arrive with interfaces attached. Data Cloud raised the traffic, because ingestion pipelines are integration work and they run on the same capacity. Agents consume interfaces, since an agent that takes action calls systems and those calls run through integration. Nobody forecasts the second order effect, because the business case for a new cloud rarely includes the integration capacity it will need. And so it surprises annually: a capacity increase requested by delivery, justified by projects that were approved somewhere else entirely, arriving on your desk as a technical necessity.
Five failures. The launch sizing never revisited, so a number from the original programme renewed unchanged for three years. Non production on the production template, because copying the pattern was faster than sizing each environment honestly. The unlimited term with no counting, giving three years of free deployment and then a renewal priced on a figure only they hold. Capacity requested without a case, approved as a technical necessity with no comparison of alternatives. And integration absent from cloud business cases, so every new product is approved without the interface cost it creates.
Last knowledge check. You are two years into an unlimited style integration agreement. What matters most before renewal? A, benchmarking the annual fee against other customers. B, measuring your own deployed capacity, so you hold a number of your own. C, asking the vendor for their view of your usage. D, deploying as much as possible before the term ends. Pause here and pick an answer before you continue.
B. An unlimited term ends with a conversation about what you actually deployed, and if the only measurement in the room is theirs, the renewal is priced against a number you cannot challenge or reduce. A is useful, and it prices the wrong thing if the quantity is wrong. C hands the baseline to the other side, and it is what most organisations do by default. And D is the instinct the model encourages, and it is exactly how a renewal doubles, because everything deployed becomes the floor you renew from. Let me set out the review that keeps you in position.
Guest analyst clip.
Twice a year, one page. Capacity by environment: reserved against used, for every environment, production and non production. Exercise frequency, meaning how often each non production environment is genuinely worked in, which is usually the most surprising line on the page. Deployed applications, and which of them serve a system that still exists. The reduction candidates, named and sized, with the risk of removing each one written beside it, because a reduction with no risk assessment gets refused by the people who run the platform. And your own capacity number, recorded every six months, so at renewal you arrive with a measurement rather than a memory.
Three sentences. MuleSoft prices capacity rather than people, so the bill is set by environment topology and reserved compute, which means an architecture decision made during delivery determines a commercial number nobody in the room at the time was accountable for. Most of the recoverable waste sits in non production: environments sized on the production template, redundancy where an outage costs nothing, and capacity held by interfaces to systems that were decommissioned, all renewed because nobody revisits a launch sizing. And integration is the line that follows every other purchase, so put it in the business case for each new cloud, and if you are inside an unlimited term, measure your own deployed capacity now.
Homework before session seventeen, about ninety minutes. One, list every environment and its capacity, reserved cores per environment, production and non production separately. Two, find the original sizing document and the date on it, then compare its assumptions against the estate you run now. Three, check redundancy below production, so every non production environment running high availability, and why. Four, count deployed applications, then ask which target systems have been decommissioned since deployment. And five, write down your capacity number, today's figure, dated, because that is the baseline you will need at renewal and it will not exist unless you create it.
Five guides, all on redresscompliance dot com. The MuleSoft licensing guide covers the platform, the editions and how the capacity model is structured. The MuleSoft pricing buyer guide sets out what the capacity lines cost and where the money concentrates. MuleSoft licensing, the unit and the bundle, works through the core as the unit and the bundle question in detail. Tableau and MuleSoft licensing covers optimising both portfolio lines, which is useful because Tableau is next session. And MuleSoft renewal describes what a renewal review covers, including the exit from an unlimited term.
That is session sixteen. The thing to take away is that this is a line where the purchase decision is made in an architecture review and the invoice arrives in your inbox, so the only useful intervention is upstream: be in the environment conversation, and keep your own count. Next time, Tableau: Creator, Explorer and Viewer, the embedded analytics question, and where it overlaps with what you already own in CRM Analytics. See you then.