Enterprise software can be deployed in many different environments, so the licensing architecture needs to account for more than how a license is created and checked.

A cloud connected desktop application, an on premise enterprise application, and software running inside an air gapped environment may all require different approaches. Understanding the main licensing architectures makes it easier to choose one that fits both the product and its customers.

Cloud Based Licensing

In a cloud based architecture, the application communicates with a remote licensing service when it needs to activate or validate a license.

This approach can simplify centralized license management. License information can be updated without distributing new license files, and licensing activity can be managed from a central system.

It works particularly well when applications have reliable Internet connectivity and the vendor wants centralized control over licensing.

The main consideration is connectivity. If the application cannot reliably reach the licensing service, the architecture needs to account for that situation.

‍

Local License Validation

Another approach is to provide the application with licensing information that it can validate locally.

Instead of contacting a remote service every time licensing needs to be checked, the application can verify a signed license locally. This can reduce the application's dependency on external connectivity.

Offline licensing is particularly useful for software deployed in restricted or disconnected environments.

The tradeoff is that license information may need to be issued, transferred, refreshed, or replaced through a separate process.

‍

License Server Architectures

A License Server provides a licensing service inside the customer's environment.

The application communicates with the local License Server instead of directly connecting to the vendor's cloud infrastructure. This can be useful when customers require licensing to remain within their own network.

A License Server can also be useful for floating licensing, where multiple installations need to share a defined number of concurrent licenses.

Devolens supports this architecture through its License Server.

Hybrid Licensing Architectures

Enterprise software does not always fit neatly into one architecture.

A hybrid approach can combine centralized cloud management with local validation or a License Server. For example, a vendor might manage licenses centrally while allowing applications to validate licensing locally when connectivity is unavailable.

This can provide more flexibility when different customers have different deployment requirements.

The architecture can also vary between products. A software vendor may use cloud based licensing for one application while providing a License Server or offline licensing for enterprise customers with restricted environments.

Choosing the Right Architecture

The appropriate architecture depends primarily on how the software is deployed and how customers need to use it.

Consider:

• Does the application normally have Internet access?
• Does the customer require licensing to remain inside their network?
• Can the application depend on an external licensing service?
• Does the product need floating or concurrent licensing?
• Does licensing need to work in air gapped environments?
• How frequently do licenses or entitlements need to change?
• How much centralized control does the software vendor require?

These requirements should be considered together rather than choosing an architecture based on one licensing feature.

For example, node locked licensing may fit an application where each installation receives its own license, while floating licensing may be more appropriate when a group of users needs to share a pool of licenses.

‍

Designing for Failure

Enterprise licensing architecture should also consider what happens when something goes wrong.

Internet connectivity can fail. A licensing service can become temporarily unavailable. A customer's internal License Server may be unreachable.

The application should have a clearly defined behavior for these situations rather than simply failing because a licensing request could not be completed.

Depending on the architecture, local validation, offline licensing, or a License Server can reduce the impact of connectivity problems.

‍

Integrating Licensing Into the Application

The licensing architecture should ultimately fit into the application's existing design.

The application needs to know when to activate a license, when to validate it, and how to respond to different licensing states. These workflows should be designed alongside the rest of the product rather than treated as an isolated component.

For a practical overview of activation and validation, see Software License Activation: How It Works and What to Consider.

Automation can also connect licensing operations to the systems that manage customers, subscriptions, and products. This can reduce the amount of manual administration required as the product grows.

‍

Building a Licensing Architecture That Can Evolve

Enterprise requirements often change over time. A product may initially require only online licensing and later need to support offline customers, floating licenses, or customer managed infrastructure.

For this reason, it is useful to consider not only the architecture required today but also the deployment environments and licensing models the product may need to support later.

A well designed licensing architecture should provide the flexibility to accommodate those requirements without forcing the software vendor to redesign its licensing system every time the product or customer base evolves.