ALA named user versus capacity metrics
The single largest variable in a Micro Focus finding is often not how much was deployed but which metric the deployment is counted under. ALA named user versus capacity metrics are the two broad ways an Additional License Authorization measures consumption: by the people authorised to use the software, or by the machine resources the software runs on. The same deployment can produce wildly different numbers depending on which metric is applied, and a finding that reaches for the costlier measure when the entitlement was bought under the cheaper one inflates the obligation before a single deployment is even examined.
This field note explains how each metric works, why the choice between them moves the number so much, and how the defensible reading holds the count to the metric the authorization actually granted. It pairs with our ALA and entitlement review track.
What a named user metric measures
A named user metric counts the individuals authorised to use the software. The unit is a person, identified and recorded, and the entitlement is a quantity of such persons. Under this metric the relevant questions are who is authorised, how an authorised user is defined, and whether the count of real users matches the licensed quantity. The hardware the software runs on is, in principle, irrelevant. A named user license does not grow or shrink because the software was moved to a larger server; it grows only when more people are authorised to use it.
What a capacity metric measures
A capacity metric counts machine resources rather than people. The unit may be cores, processors, defined units of compute, or another measure of the platform the software runs on. Under this metric the number of users is, in principle, irrelevant; what matters is the size of the environment. The defensible reading of a capacity metric depends entirely on how the authorization defines the capacity unit, a subject we treat in detail in capacity definitions in Micro Focus ALAs, because a vague or assumed definition is where capacity counts most often inflate.
Named user counts people. Capacity counts machines. A deployment licensed under one metric and counted under the other is being measured against a grant the authorization never wrote.
Why the choice of metric moves the number
The two metrics rarely produce the same figure for the same deployment, and the gap between them can be large. A small team running software on a large, shared platform looks cheap under a named user metric and expensive under a capacity metric. A large user population running on a modest platform looks the opposite. Because the metrics diverge so sharply, the single most consequential decision in a finding is which one applies, and that decision belongs to the authorization, not to the auditor. A finding that silently applies the metric producing the higher number, without establishing that the entitlement was actually bought under it, has not measured a shortfall. It has chosen one.
How a finding switches the metric
Metric substitution usually happens quietly. A deployment bought as a named user entitlement is measured by the size of the server it runs on, as though it were a capacity license. Or a capacity entitlement is recounted by the number of people with access, as though it were named user. Sometimes the substitution rides on a genuine ambiguity in the documents; more often it rides on the absence of anyone on the buyer side checking which metric the authorization specified. The correction is to read the governing authorization, confirm the metric it actually granted, and measure the deployment against that metric alone. This is the same order form discipline described in ALA metric definitions versus the order form.
Hybrid and mixed metric estates
Many estates hold both kinds of license at once, because different products, or different purchases of the same product, were bought under different metrics. This is where a finding most easily goes wrong, by applying one estate wide metric across deployments that were licensed under a mix. Each deployment must be matched to the authorization that governed its purchase and counted under that authorization's metric. An estate wide assumption that everything is capacity, or everything is named user, will overstate wherever the assumption does not match the grant. Sorting this out is part of reading layered authorizations correctly, as in stacked and superseded ALAs in a license estate.
How we defend the correct metric
Our defense begins by establishing, for every deployment in the finding, which authorization governed the purchase and which metric that authorization specified. Where the finding has applied a capacity metric to a named user entitlement, or the reverse, we restore the correct metric and recount. Where the metric is genuinely ambiguous, we read it against the order form and the surrounding terms to establish the reading the documents support, rather than the reading that inflates the number. This is the Reconstruct and Rebut work of our method, and it is the kind of metric correction that moved our E-03 case file, an ArcSight finding, from $6.0M to $1.8M, a 70 percent reduction, once the count was held to what the entitlement actually measured.
The metric is fixed at purchase, not at audit
The decisive point in any metric dispute is timing. The metric that governs a deployment was fixed when the entitlement was purchased, not when the audit opened, and nothing in an audit gives the vendor authority to choose a different one after the fact. A finding that reaches for the costlier measure is asking the buyer to accept a metric the buyer never agreed to, dressed up as a measurement result. Restoring the original metric is not a concession the vendor grants; it is a correction the documents compel. When the governing authorization specifies named user, the count is people, and a capacity reading has no standing however the deployment now runs. When it specifies capacity, the count is the defined unit, and the population of users is beside the point. Holding the metric to the moment of purchase removes the largest single source of inflation before any deployment is examined.
Closing the metric question forward
After the present finding is corrected, the forward agreement should state the metric for each product plainly, so that a future review cannot reopen the question by reaching for the costlier measure. A clean forward arrangement records whether each entitlement is named user or capacity, defines the unit, and removes the ambiguity that let the audit substitute one metric for another. Resolving the finding and fixing the metric forward are two halves of the same work. If a finding has counted your deployment under a metric you did not buy, open a case and we will hold the count to the grant.
For the full method, read the complete OpenText audit defense playbook, and for entitlement defense across the Micro Focus estate see our ALA and entitlement review track.
Counted under the costlier metric?
We match every deployment to the authorization that governed its purchase and hold the count to the metric the grant actually specified, named user or capacity, not whichever inflates the number. Open a case and recover the difference.
Open A Case →