Middleware and WebLogic

The Oracle middleware worked example.

This is a preliminary Oracle WebLogic finding taken apart line by line, showing how an inflated cluster wide claim is cut 60 to 80 percent. The preliminary number counted every core in the cluster, priced the full Enterprise edition, and applied a generic core factor, and each of those three inflations was tested against the contract and corrected before any settlement figure was agreed.

What did the preliminary finding say?

The preliminary finding said an anonymized financial services firm owed for a WebLogic deployment sized across a full virtualized cluster, priced at the Enterprise edition, using a generic processor core factor. The firm runs a modest WebLogic application on a handful of virtual cores, but those cores sit inside a large cluster that also hosts unrelated workloads. Oracle's preliminary number ignored that distinction and counted the cluster, not the application, which is the single move that turned a small deployment into a large claim.

The figure arrived inflated, as preliminary findings do, at list price and on the broadest reading of every variable. That is the expected opening position, not a settled bill. The work of the defence is to take each variable in turn, test it against the signed agreement rather than the policy paper, and rebuild the number from what the contract actually supports. This topic links up to the Oracle license compliance guide, and it sits beside Oracle middleware licensing explained.

How was the cluster wide claim challenged?

The cluster wide claim was challenged on the contract versus policy distinction, because it rested on Oracle's partitioning policy paper rather than on language written into the firm's own agreement. Oracle's position is that common hypervisors are soft partitioning, so every physical core where the software could run must be licensed, which is how a few virtual cores become an entire cluster. But that position is a policy document, and a policy document is not the contract. The firm's signed agreement did not incorporate the partitioning policy, so the claim that the whole cluster must be licensed had a weak footing.

Once the cores were limited to the cores the application actually used rather than every core in the cluster, the largest inflation collapsed. This is consistently the biggest single swing in a middleware finding, because it multiplies the count by the size of the estate. The defence here is the same one that protects a database virtualization finding: contract language beats policy, and where the wording is unclear the answer is contract dependent and resolved before any concession. For the broader principle, read contract language beats policy papers.

The three inflations and their corrections. Indicative shape based on an anonymized matter.
InflationPreliminary basisCorrected basis
Core countEvery core in the clusterCores the application actually uses
Core factorGeneric factorFactor for the actual processor type
EditionFull Enterprise editionOnly features genuinely in production

How were the core factor and edition corrected?

The core factor and edition were corrected by reading the count against the core factor table for the actual processor type and pricing only the WebLogic features genuinely in production. The preliminary number used a generic factor that overstated the licensable cores; applying the correct factor for the processor in the servers reduced the count again. Separately, the deployment had been priced at the full Enterprise edition, but the features actually in use were tested against the edition the firm had licensed, and the features that belonged to a higher edition were either not in production or could be confirmed as merely present in the install rather than used.

These two corrections are smaller than the cluster correction but they compound with it. A finding that has been reduced from the cluster to the application, then adjusted for the right core factor, then priced at the features actually used, is a different order of magnitude from the preliminary number. Any collection script output that fed the preliminary finding was reviewed first, because Oracle's scripts can overcount across virtualization layers and were part of how the cluster wide reading arose in the first place.

Definition to hold

A middleware finding inflates in three places at once: the cluster, the core factor, and the edition. Each is tested against the contract, and the corrections compound.

What was the corrected number?

The corrected number landed well inside the 60 to 80 percent reduction that an independent line by line review typically achieves on an inflated finding, because all three inflations were corrected together rather than negotiated as a single round figure. The firm did not haggle over a percentage. It rebuilt the claim from the contract, line by line, and presented the corrected figure as the defensible position. That is a stronger negotiating stance than a counter offer, because it is grounded in the agreement rather than in a split the difference instinct, and it gives Oracle a number it can accept without conceding a principle.

Get a Quote

We take your preliminary middleware finding apart line by line, test every inflation against your contract, and rebuild the defensible number. Fixed Fee or Gainshare, a share of verified savings, with no risk to you. We reduce your Oracle exposure or we reimburse our service fee.

What is the buyer move?

The buyer move is to treat the preliminary middleware finding as an opening position and rebuild it from the contract, correcting the cluster wide claim, the core factor, and the edition in turn before any settlement figure is discussed. Limit the cores to what the application uses and challenge the cluster wide reading where your agreement never adopted the partitioning policy. Apply the correct core factor for your processors. Price only the features genuinely in production. Review any script output first. Then put the corrected number to Oracle as the basis for settlement. To do this on your own finding, work across to migrating off WebLogic, the exit math and up to the Oracle license compliance guide.

FAQ

How much can a middleware finding be cut? Typically 60 to 80 percent through a line by line review, because the cluster, the core factor, and the edition are each tested and corrected against the contract.

What inflates it most? The cluster wide claim, which counts every core in the cluster rather than the cores the software uses.

What is the buyer move? Rebuild the number from the contract, correct all three inflations, and present the corrected figure as the basis for settlement.

Next step

Rebuild your middleware finding from the contract.

Get a Quote and we will take your preliminary WebLogic finding apart line by line and rebuild the defensible number.

The License Position

Read Oracle's next move before they make it.

A short weekly note, buyer side. One development, why it matters, and one move you can make this week.

Buyer side only. Unsubscribe anytime.