The estate nobody inventories: WebLogic's three editions from $10,000 to $45,000 per processor, the restricted use grants under your applications, tier drift and the SE clustering trap, and one platform's full stack bill, database plus middleware plus integration, $1.28M at list. Module 1 closes here.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
A taught session with three knowledge checks: the it-came-with-the-app question (the most common middleware finding), the WebLogic cluster arithmetic, and the 12 server audit mapping scenario. It closes module 1 by pricing a complete platform: database, middleware, and integration on one screen.
The full narration of this session, section by section, for reading and reference.
Welcome back, session five of forty, and the last session of the foundation module. Today, middleware. WebLogic, integration, analytics, the technology stack that sits between your databases and your applications. And here's what makes this estate special: nobody thinks they bought it. Application teams install it as a prerequisite, vendor installers lay it down silently, and it surfaces for the first time in an audit report. The good news is you already have every skill this session needs. The counting from session two, the options logic from session three, the cluster rules from session four, they all apply here unchanged. Today is about pointing that toolkit at the layer nobody inventories. Three knowledge checks, one full stack pricing at the end, and module one closes. Let's go.
Five takeaways today. One, you'll map the middleware stack, the five families and how each is licensed. Two, you'll price WebLogic, three editions, three very different price points, and the feature lines between them. Three, the big one, you'll learn to read a restricted use grant, the fine print that decides whether the WebLogic under your applications is free or a six figure finding. Four, you'll spot tier drift, the middleware version of session three's options trap. And five, you'll close the module by pricing a complete application platform, database, middleware, and integration, one system, three bills. By the end of today, module one's promise is delivered: hand you any Oracle deployment, and you can count it, price it, and defend it. Let's see why this layer hides so well.
Four numbers. Forty five thousand dollars, that's WebLogic Suite, per processor, at list. Middleware is not the cheap layer, the top tier rivals the database itself. Fifty to one, the processor to named user price ratio, exactly the same as the database, which means session two's breakeven rule, fifty users per processor license, works here without modification. Ten, the named user minimum per processor on WebLogic, gentler than the database's twenty five, worth knowing when you price small internal systems. And the fourth number is the word same. Same counting rules. Cores times core factor. Cluster rules from session four, fully applicable, a WebLogic VM in a general VMware cluster creates exactly the same explosion as a database VM. So mechanically, nothing new today. What's new is the blind spot: this software arrives through the side door, installed by teams who never saw a price list, and the estate builds exposure without a single purchase decision being made. That's the middleware problem in one sentence.
The stack, five families. Family one, WebLogic Server, the application server underneath most Oracle applications and plenty of custom ones. Three editions, priced per processor, we'll do the price list next. Family two, integration. SOA Suite and Oracle Data Integrator, the pipes that move data between systems. Licensed like the database, and often running on more cores than anyone remembers. Family three, analytics, the BI stack, dashboards and reporting layered on databases you already counted in session two. Family four, identity and security, directory services, access management, products that are estate wide by design, which makes their counting estate wide too. And family five, the legacy tier, Forms, Reports, old application server estates, decades old, still running payroll somewhere, still licensed, still audited. Now notice the common thread across all five: each one ships inside or underneath something else. An application needed a server. A migration needed a pipeline. A dashboard needed an engine. Every install had a reason, and none of them had a license review. That's why estates discover middleware in audits instead of inventories, and it's exactly the gap we close today.
The price list. WebLogic Standard Edition, ten thousand per processor. The base application server, perfectly capable, with one giant asterisk: no clustering. Hold that asterisk. WebLogic Enterprise Edition, twenty five thousand, and what the extra fifteen buys is exactly that, clustering and failover, the production feature set. Most real estates need EE, which is why it's the reference price. WebLogic Suite, forty five thousand, adds Coherence caching and the full high availability stack. Then the neighbors: Oracle Data Integrator at thirty thousand per processor, and SOA Suite at fifty seven and a half thousand, which, notice, is more expensive than the database itself. Two familiar rules travel with every line. NUP is one fiftieth of each figure, with the ten per processor floor. And support is twenty two percent of net, every year, on every line, forever. So a middleware estate carries the same annuity economics as the database estate. Alright, the most important concept of the session: the license that comes in the box with something else. Knowledge check one.
Knowledge check one. Your Oracle application came with WebLogic underneath it, at no extra charge, that's how it was sold. Now the dev team deploys a custom internal app onto that same WebLogic server. Is it licensed? A, yes, the WebLogic came with the application, so anything running on it is covered. B, no, the restricted use grant covers only the named application, and the custom app needs full WebLogic licenses. C, only if the custom app goes to production. Or D, WebLogic is free with any Oracle database. Pause here, and think about what the word restricted actually restricts.
The answer is B. That bundled WebLogic came with a restricted use grant, real license rights, but scoped to a named program and purpose. The moment your custom app lands on that server, the deployment falls outside the grant, and the whole thing needs full use licenses, counted cores times factor, session two style. And here's why this question matters so much: answer A is the single most common middleware audit finding in existence. It came with the app is said, in good faith, by application teams everywhere, and it's wrong just often enough to fund audit programs. C invents a production distinction that doesn't exist, use is use, session three taught you that. And D confuses WebLogic with the much narrower rights that ship with certain products. The audit test is beautifully simple: the auditor lists everything deployed on the domain, then asks which grant covers each item. Anything unmatched gets priced at list. Which means your defense is running that exact test on yourself first. Let's look at how these grants actually read.
Restricted use grants, four things to know. First, what they are: license rights bundled inside another product. The WebLogic under an Oracle application. The database that ships under a packaged tool. Real, contractual rights, you're not freeloading, but narrow ones. Second, the two restrictions, and both must hold. A named program the software may support, and a purpose it may serve. Run the named app for the named purpose, covered. Anything else on the same server, not covered, and, critically, the violation doesn't just expose the extra app, it typically unravels coverage for the whole deployment. Third, where to find them: in your ordering documents and license definitions, usually one dense paragraph with the words solely to support, or restricted use. Nobody reads that paragraph until the audit. You will read it this week, it's in the homework. And fourth, the audit test we just described: deployment list versus grant list, anything unmatched is a finding. Run it yourself quarterly and the finding becomes an internal correction instead. Sound familiar? It should, it's session three's governance loop wearing a different badge. Now some arithmetic. Knowledge check two.
Knowledge check two. Two WebLogic Enterprise Edition servers run your customer portal. Sixteen Intel cores each. What does the WebLogic cost at list? A, about two hundred thousand. B, about four hundred thousand. C, about eight hundred thousand. Or D, about fifty thousand. Pause here. It's session two's arithmetic, pointed at twenty five thousand per processor.
The answer is B, four hundred thousand dollars. Thirty two cores, times the point five factor, sixteen processor licenses, times twenty five thousand. Plus eighty eight thousand a year in support, forever. A counted one server, C forgot the core factor. And D, D priced Standard Edition, and D is secretly the most instructive wrong answer on the slide, because if that portal is clustered, and customer portals always are, then running it on SE licenses isn't a bargain, it's a finding. SE has no clustering rights at all. We'll do that trap properly in a minute. But first, zoom out and stack the bills. This same portal's database was session two's example, seven hundred sixty thousand on the processor route. Now add four hundred thousand of WebLogic on the same hardware. One business system, two layers, over a million at list, and we haven't touched integration yet. That stacking is the mental model middleware demands: every layer of the platform is its own bill, computed with the same rules, on the same cores.
Tier drift, the middleware version of the options trap. Fact one, the SE trap. Standard Edition costs ten thousand, Enterprise costs twenty five, and the difference is clustering. But the software doesn't stop you: configure a cluster on SE licenses and it works beautifully, while the estate silently consumes Enterprise Edition on every processor. The audit reads the configuration, not the invoice. Fact two, the general principle: features decide tiers. Exactly like the database options in session three, what's configured decides what you're consuming, regardless of what anyone intended to buy. Fact three, Suite creep. Coherence caching and the advanced high availability features belong to the forty five thousand dollar Suite tier. One helpful performance improvement by a well meaning engineer can nearly double the price tier of the whole estate. And fact four, the defense is the one you already know: inventory what's actually enabled, map it against the edition you own, and remediate the gap before anyone else measures it. Same trap as session three, same defense as session three. The foundation module keeps paying for itself. Now let's assemble the whole method.
The middleware governance loop, five steps, and you'll recognize the shape immediately. Step one, inventory the domains. Every WebLogic domain, every middleware install, including, especially, the ones sitting under applications. Fair warning: this list probably doesn't exist in your company today. Creating it is the whole battle. Step two, map the deployments. What actually runs on each domain, matched against your grants, full use licenses here, restricted grants there, and a third pile called unmatched that you want to find before Oracle does. Step three, check the features. Clustering, Coherence, HA configuration, which edition is each domain actually consuming? Step four, apply the math. Cores times factor per domain, and the session four cluster rules for anything virtualized. And step five, file the evidence, dated, next to the database and cluster files from the last three homeworks. One afternoon per quarter covers most estates. And notice: there is nothing in this loop you didn't already know how to do. That's why middleware closes module one, it's not a new subject, it's the final exam for the first four sessions. Speaking of which, the traps.
Five middleware traps, all field tested. Trap one, it came with the app. Knowledge check one, multiplied across every application team in the company. The restricted grant assumption is the number one middleware finding, period. Trap two, the prerequisite install. Vendor installers that silently lay down WebLogic or a database as a dependency. Installed counts, session two's rule, and there's no purchase record because there was no purchase. The audit scripts find them all. Trap three, clustering on SE, tier drift's greatest hit, production failover configured on licenses that exclude it. Trap four, the forgotten rigs. Dev, test, and training environments running complete middleware stacks. They count like production, they always have, third time we've said it in this course, and it keeps being a finding anyway. And trap five, the VMware multiplier. A WebLogic VM in the general cluster inherits everything from session four, the whole cluster claim, at twenty five thousand per processor. Middleware in general clusters is exactly as radioactive as databases in general clusters. Five traps, and every single one is caught by the loop we just built. Last knowledge check, let's test the posture.
Knowledge check three. An audit finds WebLogic installed on twelve servers. Your ordering documents show four processor licenses and one application with a restricted use grant. What's the best opening move? A, pay the difference at list. B, map every install to a grant, full use, restricted, or unmatched, before responding to anything. C, uninstall WebLogic from eight servers tonight. Or D, argue that middleware is outside the audit's scope. Pause. Sessions three and four taught you this posture. Apply it.
The answer is B, map first, respond second. And here's why the mapping matters so much: it almost always shrinks the finding before any negotiation begins. Some of those twelve installs sit legitimately under the restricted grant. Some are duplicates, dead environments, or prerequisites that never ran. What survives the mapping is a real number, known to you, documented, and that number is what you negotiate from, on your timeline, with remediation evidence in hand. A pays the three to five x opening bid, we've retired that mistake twice already. C, the overnight uninstall, is the panic move from session four's answer, mid audit it can read as evidence tampering, and it doesn't erase install history anyway. And D fails on the paper: your audit clause covers the programs you've licensed, and WebLogic is one of them. Same discipline, one more time: facts first, contract anchored, resolution negotiated. If module one has installed that reflex, it has done its job. Now, the closing bill.
The full stack, priced live, module one's graduation exercise. One business platform, the customer portal we've been carrying since session two. Layer one, the database. Sixteen EE processor licenses, seven hundred sixty thousand at list, a hundred sixty seven thousand a year in support. Layer two, the application tier we priced today. Sixteen WebLogic Enterprise licenses on the same cores, four hundred thousand, eighty eight thousand a year. Layer three, integration, ODI moving data in and out, four licenses on a smaller server, a hundred twenty thousand, twenty six thousand a year. Total: one system, three layers, one point two eight million dollars at list, carrying two hundred eighty two thousand dollars of support, every year, growing. And that's before a single database option from session three, and assuming the clean dedicated architecture from session four. Here's the takeaway to keep: when someone says what does this system cost us in Oracle, the answer has layers, and now you can compute every one of them. That's the foundation module, complete. You count, you price, you stack, you defend.
Session five, and module one, in three sentences. One, middleware is licensed exactly like the database, same metrics, same factors, same cluster rules, and it hides only because application teams install it as a prerequisite rather than buy it as a decision. Two, restricted use grants cover a named program for a named purpose, and everything beyond that scope is a full price finding waiting to be written, which is why the deployment to grant mapping is the core middleware skill. Three, module one is complete: you can count any deployment, price any stack, and you've built four homeworks worth of evidence files, which is precisely the position module two now takes into the contracts. Next session we open the paper. The master agreement, the schedules, the ordering documents, what binds, in what order, and how to build the entitlement library that every audit defense and every renewal negotiation starts from. Bring your three biggest ordering documents, we're going to read them properly. See you in session six.
Homework, about an hour, and it closes the module file. One, inventory the domains. Ask your middleware team for a list of WebLogic domains and what runs on each. When they say no such list exists, and they will, congratulations, you've found the gap, and starting the list is the assignment. Two, find the grants. Go through your ordering documents and mark every middleware line and every restricted use paragraph, the words to search are solely to support. Three, check one cluster. Pick one production WebLogic estate, which edition do you own, and is clustering configured? Ten minutes, and you'll know if you have the SE trap. Four, total the stack. For one business system, add up database, middleware, and integration, the way we just did. That number changes how your leadership sees the platform. And five, close the module file. Sessions two through five built you a dated evidence folder, counts, options, clusters, and now middleware. Label it, and bring your three largest ordering documents next week, because module two is where that folder meets the paper. See you there.
Five reads, all free on redress compliance dot com. First, hidden Oracle audit risks, where the middleware findings sit alongside the database and virtualization classics you now know. Second, how to check your Oracle license position, establishing entitlements across the whole stack, middleware lines included. Third, conducting internal Oracle license audits, the governance loop, now covering every layer module one taught. Fourth, challenging Oracle audit findings, how the mapping defense from today's last knowledge check plays out in real engagements. And fifth, dealing with Oracle sales tactics, which is your warm up for module two, the commercial conversation your contracts live inside. That's session five, and that's module one. You came in five sessions ago picturing Oracle licensing as a black box. You now count cores, price options, contain clusters, and map middleware. Next week, the contracts. See you in session six.