Key concepts

Before you start working with 10Duke Scale, learn about the key concepts.

Products

The 10Duke Scale product model enables you to issue licenses based on a predefined structure and a set of rules. Products serve as a catalog of what is being sold and licensed.

A product can have one or more product configurations, predefined product variants that a customer can buy or subscribe to. Each product configuration holds the information on what features are enabled and what license model applies.

Products and product configurations can store reference identifiers from external systems. This is useful when mapping product information between, for example, e-commerce, product data management, and customer relationship management (CRM) systems.

Your preconfigured products also help to reduce the complexity of e-commerce integration and help to keep the responsibilities between systems clear.

See how to set up your preconfigured products.

You can also define the product and feature information for a license on the fly—see more on feature licenses below in this article.

License models

A license model describes the rules that govern how licenses can be consumed, for example, the number of concurrent devices allowed per user, and how many seats a user can check out from a license.

When you’re using preconfigured products, each product configuration holds information on the license model applied. When you issue a feature license and define the features on the fly, the system applies a default built-in license model.

License model settings are stored in each license at the time a license gets issued. This means you can safely make changes to your product’s license models without affecting existing licenses.

See how to define license model settings for your preconfigured products and how to apply concurrency rules in license consumption.

Customers

The customers (licensees) in 10Duke Scale represent your customers that you issue licenses to. The customers can be individual users (B2C) or organizations (B2B).

See how to manage customers.

License consumers

While a customer is the party that you have issued a license to, a license consumer is the party who is entitled to use the license.

In B2C scenarios, the customer and the license consumer are typically the same person. But even in these cases, there may be multiple license consumers that use the same license that the customer has purchased (for example, subscriptions where multiple family members can use an application).

10Duke Scale supports three types of license consumers: a person (user), a device, and a license key.

  • A license consumer is often a user, but devices are becoming increasingly mainstream as well. 10Duke Scale supports identity-based licensing for users through integration with a standard identity provider using OAuth/OpenID Connect (OIDC).

  • The third use case, license keys, hides the true identity of who or what is consuming a license. A license key is a unique code associated with a license, and it functions as a shared secret between you, the vendor, and the license consumer who is using your licensed product. A license that has a license key can only be consumed using that license key.

See how to manage license consumers.

Licenses

A license describes the right to use a certain asset, such as a product and its features and functionalities. A license reflects part of the contract that you, the vendor, have with a customer.

See how to issue licenses.

License quantity type

Depending on the quantity type of the license, license consumption is measured in different ways:

  • A seat-based license anchors the use of the license to a computer (a device in more general terms), or limits the number of concurrent instances of the client application.

  • A use count-based license counts the unique consumption of a specific entity in the client application. The counting takes place in the client application, and 10Duke Scale maintains the total remaining quantity and the change to it as reported by the client application.

  • A use time-based license counts the total aggregated use time of a license. Measuring the time takes place in the client application, and 10Duke Scale maintains the total remaining quantity and the change to it as reported by the client application.

Product vs. feature licenses

You can apply product and feature information to licenses in two different ways:

  • Set up predefined products in 10Duke Scale, with product configurations that include the feature names as well as a license model, and use these to issue licenses.

    When issuing licenses using this option, all you need to know is the product configuration ID, the customer that you’re issuing the licenses to, and the quantity that you’re granting in the license.

    Preconfigured products are always needed when issuing licenses using activation codes.

  • Issue licenses and specify the product and feature names on the fly—in 10Duke Scale these are referred to as feature licenses.

From the license consumption point of view, both options result in the same kind of a license structure. Both types of licenses specify a product name and a list of feature names, and the only difference is that product-based licenses also specify the product configuration that was used.

License containers

Licenses are stored in customer-specific license containers, which are used to control license consumers’ access to licenses, and which help you organize customers’ licenses.

While one license container is typically enough for a B2C customer, there may be use cases where you want to use multiple license containers for B2B customers.

For example, if a B2B customer has purchased multiple licenses with different usage constraints or features, they would typically want to control which of their users can access each purchased license.

See how to manage license containers and how to use them to manage access to licenses.

License consumption

A license can be consumed either in enforced or metered mode:

  • In enforced licensing, the license specifies a certain quantity that is consumed when the license is used.

    Depending on the quantity type in the license, the quantity can be the number of seats available in the license, or the use count or amount of use time that the license allows. Enforcing the consumption of the quantity takes place at the time of the checkout.

  • In metered licensing, the quantity being consumed is not limited. 10Duke Scale tracks the license consumption (the seats in use, the use count, or the use time) based on API interactions, and the usage statistics are available through 10Duke Scale metrics and insights.

In both enforced and metered consumption, the interaction protocols are used to start the consumption of a license, to acknowledge and authorize the continued consumption of the license, and to communicate the end of the consumption of the license.

In enforced licensing, these actions are done with a checkout, heartbeat, and release message. In metered licensing, the start and end messages replace the checkout and release, but there is still a heartbeat message.

When use count or use time is being consumed, the client application should inform the 10Duke Scale License Checkout API of the final used quantity in the release or end message. In metered licensing, this information is used for tracking the consumption. In enforced licensing, any difference between the consumed quantity and the quantity pre-allocated at checkout is either refunded to or deducted from the quantity in the license.

The license checkout is based on the product name in the license. A license can be checked out by a user or a device, and key-based licenses can be checked out anonymously using a license key.

As a result of a successful license checkout, the application receives a license token from 10Duke Scale in JSON Web Token (JWT) format. The license token carries information about the license to the client application.

See how to consume licenses.

Feature flags

Feature flags, also referred to as feature toggles, provide a license consumer-oriented view into what products and features are available for use through all the licenses that the license consumer has access to.

Feature flags allow you, the vendor, to modify the system and application behavior without changing code, which is useful, for example, for enabling and disabling features and functionalities in the application.

To understand the general concept of feature flags, check out martinfowler.com.

10Duke Scale feature flags are driven by licenses, with the main difference to regular licensing that requesting feature flags for a license consumer doesn’t consume the licenses. This is a benefit if licenses are the required driver, but it’s not feasible to limit their use by quantity or to meter the use and invoice accordingly. 10Duke Scale is unable to track the use of the features because there’s no license consumption, so the application needs to track feature usage by some other means.

Example use cases for feature flags:

  • Provide new features for evaluation or deliver new functionality to users rapidly but safely.

  • Drive available features by geographic area, based on using different product configurations per geographic area where the product is supplied to.

  • Drive seasonal or campaign-based availability of features, based on using time-limited product configurations. 10Duke Scale provides the product configuration and licensing aspect and, for example, the e-commerce system is responsible for determining the coupling between a seasonal offering and the correct product configuration to use.

Examples of technical purposes:

  • Ship alternative code paths within one deployable unit and choose between them at runtime.

  • Provide features and functions based on licensing without involving the license consumption aspect.

If you’re applying feature flags, the basic questions that must be answered are how long a feature flag will live, and how dynamic the toggling decision must be. The benefit of license-driven feature flags is native support for answering both of these questions.

The feature flag API returns a super-set of a product/feature breakdown, which means the application that consumes the information is completely decoupled from the license instances that drive the result. The license validity time frame answers the question “how long”, and expiring licenses and issuing of new licenses with evolving product configurations answer the question “how dynamic”.

See more information on retrieving feature flags.

Contents