Variant Management

This article provides a brief breakout discussion on variant management and its strategic implications—a topic with significant potential for deeper exploration in the future.

„All development occurs at head.“ – Software Engineering at Google, 20201

Supporting multiple Variants

As teams define the product to be modeled, questions about versions, configurations, and variants often arise. Supporting multiple versions, configurations, and variants is common, but it also adds significant overhead in areas such as management, coordination, development, testing, release management, and support. The table below provides an overview of these terms, their meanings, and key aspects.

Concept

Definition

Key Points

Examples

Version/Release

A version is a  unique state in the evolution of a product over time, marked by incremental improvements or significant shifts in architecture or technology.

While a Version often represents an internal state of the product, a Release represents the delivery of a Version to the customer (external visible state), usually with a certain level of quality.

-Represents product maturity and lifecycle
-Can have plateaus when major redesigns occur.
-Semantic Versioning2:
• Major = incompatible interface changes (v2.0.0)
• Minor = backward-compatible features (v2.1.0)
• Patch = backward-compatible fixes (v2.1.3)
• plus evtl. Pre-Release or Build Metadata

• Software: v2.1.3 → v3.0.0
• Car platform Gen1 → Gen2

Configuration

The specific arrangement of options, parameters, or features that define customer- or system-specific behavior and functionality within a given version or variant.

-Describes how a product is set up or behaves.
-In DevOps/SCM, refers to controlled state definitions of systems (“configuration management”).
-In software, configurations may become so distinct that they effectively create new variants.

• Car with long-range battery + premium sound system.
• Software with specific modules enabled.

Variant

A parallel model of the same product platform, designed to serve different markets, segments, or use cases. Often created via platform sharing, clone-and-own, or similar approaches.

-Exists in parallel, not sequential like versions.
-Built on a shared platform but differentiated for distinct needs.
-Supported by product line engineering and variant management practices.

• Sedan vs. SUV on the same platform.
• iPhone 14 vs. iPhone 14 Pro.


This opens the door to a strategic discussion: Does multi-version development truly deliver value, or is it simply a legacy of past decisions? And how many variants should a vendor build to strike the right balance between market needs, development costs, and speed of delivery?

Rethinking Versions: The Case for Single-Version Development

Many modern, high-performing organizations have shifted to single-version development – a model where all users are served through a continuously evolving, unified version of the product. This approach drastically reduces complexity, improves velocity, and simplifies operations. Some examples:

  • iOS: Apple delivers a single, tightly controlled OS version that rolls out to nearly all users within weeks.
  • Salesforce: All customers run on a single core version, with flexibility delivered through configuration, not code.
  • Google Chrome / Microsoft Edge: Always up to date via auto-deployment – no user-managed versioning.
  • SaaS platforms like GitHub, Slack, or Zoom, using feature flags to customize experience without fragmenting the codebase.

Advantages

Adopting a single-version mindset encourages architectural discipline, supports continuous delivery, and enables faster learning through unified telemetry and feedback. While not always feasible in every context (e.g., embedded or regulated systems), it’s worth challenging the status quo—especially when modeling reveals just how much complexity comes from maintaining variants.

Approach

Description

Benefits

Challenges

Single-version development

All users are served through one continuously evolving version of the product.

– Reduced complexity
– Faster delivery velocity
– Simplified operations and support

– Requires strong CI/CD pipeline
– Users must adapt quickly to changes

Multi-version development

Multiple product versions are maintained in parallel to serve different user groups, regions, or regulations.

– Supports legacy customers
– Flexibility for regional/regulatory needs

– High operational complexity
– Slower delivery velocity
– More costly to maintain

References

  1. Winters, T., Manshreck, T., & Wright, H. (2020). Software Engineering at Google: Lessons learned from programming over time. O’Reilly Media. ↩︎
  2. see https://semver.org/ ↩︎

Author: Peter Vollmer – Last Updated on September 10, 2025 by Peter Vollmer