A strategic guide for CIOs, SAM managers, and IT procurement heads on IBM's flexible shared licensing models. Covers floating (concurrent user) licensing, token-based licensing across product suites, sizing strategies, compliance considerations, real-world examples, and best practices for maximising value while staying audit-ready.
In a floating or concurrent user model, software is not tied to a specific named user. Instead, a set number of licences can be used simultaneously by anyone in the organisation, up to the limit at any given time. IBM implements floating licensing via a licence server that tracks current usage.
| Aspect | Named User Licence | Floating (Concurrent) Licence |
|---|---|---|
| Assignment | Tied to one specific individual | Shared pool — any authorised user |
| Access | Always available to that user | Available if pool has a free slot |
| Typical Ratio | 1 licence per user | 1 licence per 2–4 users (varies by usage) |
| Per-Licence Cost | Lower | Higher (flexibility premium) |
| Total Cost (Large Team) | Higher (licence per person) | Lower (fewer licences needed) |
| Infrastructure | No licence server required | Requires IBM Licence Key Server or FlexLM |
You purchase a set number of floating licences (e.g., 10). Up to 10 users can run the software concurrently. An 11th user is blocked until someone exits. The software checks out a licence from the server on launch and returns it when closed.
Floating licences cost more per seat than named-user, but you need far fewer. Instead of 40 named licences for 40 users, 15 concurrent licences may suffice — potentially halving total cost. The savings are dramatic for large teams with occasional users.
Requires a licence manager application (IBM Licence Key Server, Flexera FlexLM, or IBM Common Licensing) installed on a server. Users' software connects to this server to check out and return licences automatically.
Concurrent licensing is common in engineering and analytics tools — IBM SPSS, IBM Rational (now partly HCL), and IBM Domino server CALs have all offered concurrent user options.
Token-based licensing provides a pool of licence tokens — virtual credits consumed in different quantities by different IBM software or features. Instead of buying X licences of each product, you buy a single pool of tokens that flexes across the portfolio.
| Aspect | Floating Licence | Token-Based Licence |
|---|---|---|
| Scope | One product per pool | Multiple products share one pool |
| Currency | Licence seats | Tokens (consumed at different rates per product) |
| Flexibility | User count flexibility | User count + cross-product flexibility |
| Ideal For | Single product, many occasional users | Multiple products with variable demand |
| Availability | Most IBM desktop/server products | Specific suites (Rational, Maximo, some Cloud Paks) |
A token pool covers multiple tools. IBM Rational token packs historically worked across Team Concert, DOORS, Rhapsody, etc. Each product consumes a defined number of tokens per user — e.g., 1 token for DOORS, 3 tokens for a higher-end tool.
Usage fluctuates day-to-day across products. The token system dynamically allocates capacity — preventing the scenario of unused licences for one product while another is short. Tokens return to the pool when users close applications.
If you only ever use one product heavily, tokens can be more expensive than direct licences. But with many products and sporadic usage, tokens add enormous flexibility. Pricing is based on token count — one pool roughly equating to a projected mix of use.
| Product Family | Token Model | Notes |
|---|---|---|
| IBM Engineering (Rational) | Token packs across ELM suite | DOORS, Rhapsody, Team Concert, Test Management |
| Maximo Application Suite | AppPoints (token equivalent) | Asset Management, Monitor, Health, Predict — all share one pool |
| Cloud Pak for Automation | Token-style entitlements | Various automation modules consume from shared pool |
| Cloud Pak for Data | Virtual Processor Core tokens | Different services consume at different rates |
If not all users need software simultaneously, floating licences prevent paying for idle capacity. With tokens, you avoid purchasing separate fixed licences for multiple products — some of which would sit unused at any given time.
Floating licences accommodate shifting usage within a team. Token licensing goes further — accommodating shifting usage across different applications. Ideal for diversified IBM software portfolios.
Instead of tracking entitlements for five different products, you manage one token pool. IBM provides a token licence server that counts token check-outs — simplifying compliance tracking to a single metric.
Need more concurrent users? Add licences or tokens to the pool and everyone benefits. If usage drops, you aren't stuck with named licences assigned to former employees — pools automatically adjust to active user counts.
IBM sometimes includes token pools in enterprise agreements for greater agility. A negotiated token pool shared among dev and test tools makes it easier to distribute costs internally based on actual use.
If the licence server goes down, users can't start software. Ensure high availability — redundant servers or backup licence keys for emergencies. Server outages directly impact productivity.
Floating and token models demand good tracking. While over-usage is blocked in real-time (software denies access), IBM audits will check that your purchased count matches your peak usage. Monitor denials — frequent denials signal you need more licences.
Some floating licences are restricted by geography or network subnet. Ensure your agreement matches your deployment — global teams may need separate pools per region if licence files are geographically restricted.
Understanding how many tokens each product consumes is vital. IBM provides tables, but rates can change with versions or IBM adjustments. Always refer to the latest token usage table — an upgrade might consume more tokens if features expanded.
IBM often sells token packs with minimums (e.g., 100 tokens). Smaller organisations may not use enough breadth to justify tokens. For very small user counts who use software all day, named licences may actually be cheaper.
In an audit, IBM requests proof of entitlements and usage logs. Retain proof of purchase, configure IBM audit tools (ILMT for PVU, token server reports for tokens), and archive usage logs. For user-based metrics, the onus is on you to demonstrate control.
Study user behaviour over at least one month. Find peak concurrent usage to size the pool. If peak was 18 users once but normally 10, buy 12–15 and manage the occasional spike through scheduling. Data-driven decisions prevent over-buying.
Global teams can share floating licences across time zones (Europe and Americas use software at different times). Ensure your terms allow this and implement a follow-the-sun licence server configuration for maximum pool efficiency.
Periodically review IBM's token reports showing maximum tokens in use. If you consistently use only 50 of 100 tokens, reduce at renewal. If hitting limits and getting denials, plan to add tokens to avoid productivity loss.
Train users to close applications when not actively using them. Configure idle timeout features so licences automatically return to the pool after X hours of inactivity. This single practice can dramatically improve pool utilisation.
Some products allow "borrowing" a floating licence for offline use (e.g., engineer going offsite). This reduces the available pool and can cause compliance issues if not tracked. Use borrowing sparingly, keep borrow periods short, and monitor via the server admin console.
Assign a dedicated licence manager or SAM role to oversee pools. They should check usage reports frequently, update licence files when purchasing more, and coordinate with IBM on changes. Centralisation prevents different teams from monopolising licences.
ILMT doesn't manage user-based licences, but SAM tools like Flexera or ServiceNow can integrate licence server logs for a full picture. Invest in automation that alerts you when nearing capacity — don't wait for user complaints.
| Scenario | Recommended Model | Why |
|---|---|---|
| Engineering/technical teams — large team, sporadic use of heavy software | Floating | 25 engineers but only 10 active concurrently — floating cuts costs by 60%+ |
| Multiple IBM product suites — Maximo, Cloud Pak, Rational | Tokens | Usage of each component varies daily — tokens flow to the area of need |
| Consulting/training environments — rotational users across projects | Floating | Different project teams/trainees use software at different times — concurrent pool serves all |
| Cost-constrained departments — limited budget, broad access needed | Floating | "20 people, 5 concurrent licences" is easier to approve than 20 separate purchases |
| Small team, constant daily use — 3 users who live in the tool all day | Named User | No sharing benefit — floating costs more per seat with no concurrency savings |
| Single IBM product, no suite — one tool with predictable user count | Named User or Floating | Tokens only add value across multiple products — single product doesn't benefit |
Before implementing, audit current usage. Identify peak concurrent needs and total unique users. This informs optimal purchase quantity that balances cost and user satisfaction — never buy "just in case."
If unsure, err on a slightly smaller pool initially — you can usually add licences or tokens quickly if you underestimated. It's better to start lean and monitor than to over-provision from day one.
When setting up a token agreement, negotiate the ability to reallocate tokens as needs change. Ensure the agreement covers all products you intend to use — including new modules IBM might release under that programme.
Have at least two people in IT familiar with operating IBM's licence management tools. Ensure documentation exists for updating licence files, interpreting usage logs, and troubleshooting client connectivity.
In some cases, separate pools for different groups or geographies make sense — for cost allocation or to prevent one team from monopolising licences. But don't fragment so much that you lose pooling efficiency.
Set up regular reports on licence utilisation. If licences are maxed out by afternoons, use that data to justify budget for expansion. Celebrate efficiency gains — "80% utilisation means we've minimised waste and saved $X vs individual licensing."
Revisit the concurrent ratio as your user base grows. 10 floating licences for 30 users might work today, but at 60 users you'll need more. Re-evaluate annually or with major staffing changes.
Some token licences have restrictions on non-production use or require base licences. Always read the fine print. If unclear, pose hypothetical usage scenarios to IBM and get their approval in writing to avoid audit surprises.
IBM sometimes offers conversion of older floating licences to tokens or vice versa. Stay in touch with your IBM account rep or licensing partner to take advantage of these if they align with your strategy.
Engaging IBM licensing specialists can identify opportunities — consolidating separate product licences into a token model for savings, or the reverse. A short engagement can yield significant ROI in licence optimisation.
A named user licence is assigned to one specific individual — only that person can use the software, even if they're idle. A floating licence isn't tied to anyone; it floats among authorised users with a concurrent limit. One floating licence could service 3–5 people if they use the software at different times, whereas named licences require one per person regardless of concurrency.
Typically no. IBM provides the licence server manager (IBM Common Licensing, Rational Licence Key Server) as part of your entitlement. You just need a server (can be a VM) to run it — a minor infrastructure cost. Always download the version that matches your product version for compatibility.
In many cases, yes. You might give 10 heavy users named licences and serve 20 occasional users with 5 floating licences. You'll need to manage these as separate entitlements and configure software installations differently (licence server for floating, local licence for named). Track compliance separately for each group.
The next user receives a "licence not available" message and is blocked until someone else logs off. This is why monitoring and right-sizing are critical. Establish internal policies — instruct users to close applications when done, especially on shared-licence software.
No. Token licensing is available for specific suites — historically IBM Rational (Engineering Lifecycle Management), Maximo Application Suite (AppPoints), and some Cloud Paks. You can't apply tokens to any IBM software arbitrarily — it must be under a token-capable programme. Check IBM's documentation or ask your account rep.
IBM will request usage logs from your token licence server (typically the last 12 months). They check your peak token usage against what you purchased. Regularly archive and review logs yourself, retain Proof of Entitlement documents, and maintain records of any token reallocations. Audits are straightforward if records are in order.
Yes, if the user can reach the licence server over the network. Ensure the server is accessible via VPN or configured in a DMZ for remote access. Watch for latency — very slow connections may have trouble maintaining the heartbeat. If VPN drops, the server may hold the licence for a timeout period, temporarily reducing the available pool.
"Authorised User Single Install" means a specific user can use the software on only one machine. It's still user-specific (named), unlike floating licences which aren't tied to individuals at all. The "single install" constraint limits device count, not user identity — a separate concept from concurrent licensing.
Usually yes — token pools cover usage regardless of environment. If dev and production both draw from the same pool, that's typically allowed. Verify whether your terms require separate pools for different environments, but from IBM's side, a token is a token regardless of where it's consumed.
Share your IBM estate details. We'll assess your floating and token licence positions, identify optimisation opportunities, and build a compliance-ready strategy — typically within 48 hours.