6.8 Multiple Products, Platforms, and Implementations

Go To Top

Return to Prerequisites and Tooling

The tool 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 DDS category may include more than one approved DDS product because DDS defines interoperability expectations across conforming implementations. Later phases may test the same IDL definitions, topics, QoS assumptions, and Node behaviours across multiple DDS vendors. Each approved DDS product should therefore record its own version range, setup requirements, type-generation commands, runtime libraries, 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, 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:

1. Product or platform name.
2. Vendor, project, or source.
3. Required version or acceptable version range.
4. Product status.
5. Required, recommended, optional, experimental, not applicable, or to-be-decided classification.
6. Applicable role or environment.
7. Phase, build, test, demonstration, or deployment purpose.
8. Installation or setup reference.
9. Verification command or validation method.
10. Product-specific generation, build, runtime, or Configuration notes.
11. Interoperability expectations, where applicable.
12. Owner or responsible role.
13. Related implementation decision record, where applicable.
14. 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:

1. Primary baseline: the product used for normal development, testing, demonstration, and acceptance.
2. Supported alternative: a product the team allows and validates for the same capability.
3. Interoperability target: a product the team uses to test cross-product compatibility.
4. Experimental: a product the team may explore but does not treat as part of the controlled Baseline.
5. Not applicable: a product or category that does not apply to the specific phase, build, or environment.
6. 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 Evidence.