# The heterogeneous fleet problem nobody admits: what Redfish doesn't normalise (Problem Specifics 4/5) > Why Redfish gives Dell, HPE and other BMCs a common API but not common BIOS settings or event messages, and what a normalisation layer has to do across vendors. - URL: https://blog.asama.ai/blog/issue-09-asama-the-heterogenous-problem-nobody-admits/ - Author: Sumeet Ghosh - Published: 2026-02-27 - Tags: Fleet problems A heterogeneous fleet runs servers from more than one vendor, and each vendor's BMC reports health, settings and events in its own format. Redfish, the DMTF's standard management API, gives them a common transport and schema, but BIOS attributes, OEM extensions and event wording stay vendor-specific, so correlating, comparing and fixing across vendors still takes a normalisation layer. Ask any infrastructure vendor about multi-vendor environments and they will tell you their product supports them. Ask an infrastructure engineer who manages a multi-vendor fleet and they will tell you what that support actually looks like in practice: different telemetry formats, different management APIs, different firmware update mechanisms, different alert schemas. Most infrastructure teams run more than one vendor. This is not a choice that reflects poor planning. It reflects procurement reality: no single vendor wins every RFP, hardware generations overlap, and supply chain constraints mean you take what you can get on the timeline you need. The heterogeneous fleet is not an edge case. It is the norm. > "The tools built for homogeneous environments fail in heterogeneous ones not because they are bad tools, but because uniformity is baked into their assumptions." --- ## Where the failures show up > ### Telemetry correlation > > **What breaks** > Events across Dell BMCs, HPE iLOs, and other vendor systems exist in isolated management planes. > > **Operational reality** > Two causally related hardware events on the same network may never be correlated because they originated from different vendor interfaces. --- > ### BIOS baseline comparison > > **What breaks** > A [golden baseline](https://blog.asama.ai/blog/issue-02-asama-config-drift-is-the-silent-killer) for Dell PowerEdge hardware is fundamentally different from one for HPE ProLiant systems. Take one intent, running the cores at full performance: on a PowerEdge it is `SysProfile=PerfOptimized`; on a ProLiant it is a [Workload Profile](https://www.hpe.com/psnow/resources/ebooks/a00112581en_us_v4/Workload_profiles_perf_options.html), such as General Peak Frequency Compute, which sets Power Regulator to Static High Performance and locks it. > > **Operational reality** > The tooling that validates one hardware stack usually has no awareness of the others. --- > ### Firmware update workflows > > **What breaks** > Vendors use different update mechanisms, validation sequences, and rollback procedures. > > **Operational reality** > Most infrastructure teams end up maintaining fragmented maintenance workflows that behave differently across the fleet, and [each one ages](https://blog.asama.ai/blog/issue-04-asama-your-automation-has-an-expiry-date) as the fleet changes under it. --- ## What the integration layer actually requires A genuine integration layer for heterogeneous infrastructure is not a dashboard that aggregates vendor-specific metrics into one screen. It is a system that normalises data from different vendors into a common operational model, so that events across Dell, HPE, Supermicro, and others can be correlated, compared, and acted on using the same reasoning logic. Redfish helps, but it doesn't finish the job. It standardises how you ask a BMC for its BIOS settings; the settings themselves are, in [the DMTF schema's words](https://redfish.dmtf.org/schemas/v1/Bios.v1_0_13.json), "specific to the manufacturer or provider", and each platform publishes its own attribute registry. What a vendor adds beyond the standard sits under Oem extensions. This requires going below the vendor's management interface to the underlying hardware telemetry, and understanding how different vendors represent the same physical reality in different data formats, down to [the SMART raw values on their drives](https://blog.asama.ai/blog/issue-06-asama-what-smart-data-isnt-telling-you). It is the integration work that every heterogeneous fleet team ends up doing themselves, in ad-hoc ways, repeatedly, without ever quite finishing. --- ## From Asama > ### One model across vendors > > Asama is designed for heterogeneous fleets as the baseline case. > > Our normalisation layer is designed to translate vendor-specific telemetry across Dell, HPE, Supermicro, and others into a common operational model that enables: > > - Fleet-wide event correlation > - Cross-vendor baseline comparison > - Unified remediation workflows > - Consistent operational reasoning regardless of hardware vendor --- ## Food for thought > How many separate management interfaces does your team use to operate a fleet that shares the same physical network, and what does that context-switching actually cost? **Update, October 2026.** Asama's fleet visibility is generally available. It reads each BMC out-of-band over Redfish and IPMI and normalises what each vendor reports into one object per physical part, so a Dell power reading and an HPE power reading become the same quantity. One model covers Dell, HPE, Lenovo, Supermicro and NVIDIA hardware, and detection built on it has been validated on Dell, HPE and Lenovo hardware; investigation and remediation are expanding. To see your mixed fleet in one model, book a live comparison against your stack at [asama.ai](https://www.asama.ai), or write to contactus@asama.ai.