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 variants and versions often surface. While it’s common for organizations to support multiple versions or configurations of a product, this complexity can significantly increase overhead – e.g. in management, coordination, development, testing, release management, and support.
This opens the door to a strategic discussion: Is multi-version development truly delivering value, or is it a legacy of past decisions?

Rethinking Variants: 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.

Hardware

This concept also applies to hardware, where a modular architecture enables the development of individual components or subsystems as separate value streams. Each module can be designed, built, and tested independently—then integrated into the larger system. This not only supports scalability and parallel development but also aligns well with the value stream approach by allowing teams to focus on delivering distinct, manageable pieces of value.‍

References

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