6.8 Multiple Products, Platforms, and Implementations [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 6.8 Multiple Products, Platforms, and Implementations ======

[[fxdemo:05-part:start | Go To Top ]]

[[fxdemo:05-part:06-prerequisites-and-tooling:start | Return to Prerequisites and Tooling ]]

The tool [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] checklist should allow each tool category to identify one or more approved products, platforms, or implementations. A tool category represents a required capability, not necessarily a single vendor product. This distinction matters when the architecture or demonstration intentionally supports interoperable or substitutable implementations.

For example, the [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] category may include more than one approved DDS product because DDS defines interoperability expectations across conforming implementations. Later phases may test the same [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]] definitions, topics, QoS assumptions, and [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] behaviours across multiple DDS vendors. Each approved DDS product should therefore record its own version range, setup requirements, type-generation commands, runtime libraries, [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] conventions, validation method, and interoperability status.

The same pattern may apply to other tool categories. A phase may support more than one container runtime, build tool, Java distribution, Python distribution, [[dido:99_annexes:annex-b-terms-and-definitions:r:repository|Repository]] platform, operating system, package manager, test runner, documentation generator, or CI runner image. The checklist should record which products the phase supports, which product acts as the primary Baseline, and which products count as supported alternatives.

Each product entry within a tool category should capture:

  - Product or platform name.
  - Vendor, project, or source.
  - Required version or acceptable version range.
  - Product status.
  - Required, recommended, optional, experimental, not applicable, or to-be-decided classification.
  - Applicable role or environment.
  - Phase, build, test, demonstration, or deployment purpose.
  - Installation or setup reference.
  - Verification command or validation method.
  - Product-specific generation, build, runtime, or Configuration notes.
  - Interoperability expectations, where applicable.
  - Owner or responsible role.
  - Related implementation decision record, where applicable.
  - Exceptions, constraints, or open risks.

When a tool category includes multiple approved products, the checklist instance should identify the primary Baseline product and any supported alternatives. The primary Baseline product defines the minimum environment that the team uses for normal development, testing, demonstration, and acceptance unless the phase-specific checklist states otherwise.

The checklist should distinguish the following product statuses:

  - Primary baseline: the product used for normal development, testing, demonstration, and acceptance.
  - Supported alternative: a product the team allows and validates for the same capability.
  - Interoperability target: a product the team uses to test cross-product compatibility.
  - Experimental: a product the team may explore but does not treat as part of the controlled Baseline.
  - Not applicable: a product or category that does not apply to the specific phase, build, or environment.
  - To be decided: a product or category that remains unresolved and requires an implementation decision.

For DDS, the checklist should also capture whether the phase requires single-vendor operation, multi-vendor build compatibility, multi-vendor runtime interoperability, or only future interoperability planning. If the team tests multiple DDS vendors, the checklist instance should record which combinations the team verified and where it stores the supporting [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]].

----

<WRAP centeralign>

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

</WRAP>