Licence Costs
Software licensing whose pricing model frequently constrains architecture more than its technical characteristics do.
Definition
Licence cost is not a fixed line item; it is a function of something your architecture controls, and the choice of metric can make an otherwise sensible design uneconomic.
The models and their architectural consequences
| Model | Architectural pressure |
|---|---|
| Per core or per socket | Fewer, larger machines; penalises horizontal scaling and containers |
| Per user or per seat | Careful account lifecycle management; penalises broad access |
| Per instance | Consolidation; penalises microservices and per-tenant deployment |
| Per request or per unit | Caching and batching become cost levers |
| Per environment | Fewer non-production environments; penalises good testing practice |
The pattern worth noticing: a per-core database licence can make horizontal scaling more expensive than vertical scaling, inverting the architecture you would otherwise choose. That is a commercial constraint producing a technical decision, and it should be recognised as such rather than rationalised after the fact.
Where the surprises come from
- Non-production environments licensed at production rates, which can double the cost of good testing practice and quietly discourages it.
- Disaster recovery capacity licensed even when idle.
- Containers and virtualisation, where licensing may count physical cores on the host rather than allocated cores.
- Audit true-ups. A vendor audit finding under-licensing produces a bill plus penalties, and it is a real risk in large estates.
- Renewal leverage. A product deeply embedded with high exit cost has no negotiating position at renewal, and the vendor knows the exit cost as well as you do.
The strategic question
What is the exit cost? A licence whose price rises 40% at renewal is only a problem if you cannot leave. Preferring open standards and open protocols — even with a commercial implementation — preserves the option, and that option is what constrains the renewal conversation.
This is also the argument for preferring managed versions of open interfaces over proprietary ones at similar cost: the migration path is a restore rather than a rewrite.
Failure scenarios
- Architecture designed without checking the licensing model, then found uneconomic at scale.
- Non-production licensing discouraging realistic testing.
- Licence terms changed by the vendor, with an embedded product and no alternative.
- Under-licensing discovered by audit.
Interview question
"A per-core database licence makes horizontal scaling more expensive than vertical. How does that change your design, and would you challenge the constraint?"