Lieferantenabhängigkeit ist kein Einkaufsproblem — es ist ein Architekturproblem

Wann das Problem sichtbar wird

Es passiert fast immer zum denkbar ungünstigsten Zeitpunkt. Ein Schlüsselbauteil wird abgekündigt. Ein geopolitisches Ereignis unterbricht die Lieferkette. Ein Qualitätsproblem in der Produktion erzwingt ein Redesign. Und das Engineering-Team stellt fest: Den Chip zu tauschen heißt Firmware neu schreiben, das Produkt neu zertifizieren, möglicherweise das Gehäuse neu werkzeugieren.

Das ist Lieferantenabhängigkeit. Fast jedes Hardware-Unternehmen, mit dem ich arbeite, hat sie — oft ohne es zu wissen.

Die übliche Diagnose: ein Einkaufsproblem. Nur eine Quelle, keine Alternativen qualifiziert, keine Dual-Source-Strategie. Mag alles stimmen. Aber es ist die falsche Analyseebene.

Warum der Einkauf es nicht richten kann

Der Einkauf kann alternative Lieferanten finden. Was er nicht kann: dafür sorgen, dass diese Alternativen tatsächlich austauschbar sind. Wenn die Firmware direkt gegen das proprietäre SDK eines Herstellers geschrieben ist — wenn der HAL (Hardware Abstraction Layer) der HAL des Herstellers ist — dann heißt Lieferantenwechsel nicht Bauteile umbestellen, sondern Software neu schreiben.

Das ist die architektonische Abhängigkeit. Sie entsteht, weil Hardware-Teams unter Zeit- und Kostendruck den Weg des geringsten Widerstands nehmen: Referenzdesign des Herstellers, dessen SDK, dessen Beispielcode. Das Produkt wird ausgeliefert, es funktioniert. Und die Abhängigkeit bleibt unsichtbar — bis sie es nicht mehr ist.

Die richtige Frage

Die entscheidende Frage lautet nicht: "Haben wir einen Ersatzlieferanten?" Sondern: "Wie viele Engineering-Stunden kostet es, dieses Bauteil durch eine Alternative zu ersetzen?"

Wenn die Antwort mehr als ein paar Tage ist, haben Sie ein Architekturproblem. Das Bauteil hat sich in die Geschäftslogik eingefressen. Ihr System ist nicht modular — es ist an der Hardware-Schnittstelle monolithisch.

Was gute Architektur ausmacht

Ein sauber architekturiertes Hardware-Software-System behandelt die Hardware-Schicht als austauschbare Abhängigkeit. Konkret:

• Schnittstellenverträge an der Hardware-Grenze definieren: Was braucht der Rest des Systems von diesem Bauteil? Eine Netzwerkverbindung. Einen Sensorwert. Einen Speicherzugriff. Keinen bestimmten Chip.
• Eine dünne Abstraktionsschicht, die zwischen diesen Verträgen und dem konkreten Hersteller-SDK übersetzt. Nur diese Schicht kennt den spezifischen Chip.
• Die Abstraktion validieren, indem das System gegen eine Mock-Implementierung kompiliert und getestet werden kann — bevor die echte Hardware verfügbar ist.

Das ist Standard-Software-Engineering. In der Cloud-Welt wird es routinemäßig so gemacht. In Embedded-Firmware deutlich seltener — dort liegt der Fokus traditionell auf Performance und Ressourceneffizienz, nicht auf Austauschbarkeit.

Die China-Dimension

Für Unternehmen, die aus China beziehen, ist das Problem besonders akut — aus zwei Gründen.

Erstens: Chinesische Komponentenhersteller — insbesondere bei Mobilfunk-IoT-Modulen (Quectel, SIMCom, Fibocom) und SoCs (Espressif, Rockchip) — liefern tief integrierte SDKs, die darauf ausgelegt sind, ihre Bauteile einfach nutzbar und schwer ersetzbar zu machen. Keine böse Absicht — gute Produktstrategie. Aber der Standardweg führt direkt in die Abhängigkeit.

Zweitens: Die Dokumentationslücke verschärft das Problem. Chinesische Hersteller veröffentlichen zwei Ebenen: ein englisches Datenblatt für internationale Kunden und eine tiefe technische Referenz — Applikationshinweise, Register-Maps, undokumentierte Funktionen — die nur auf Mandarin existiert. Wer mit der englischen Dokumentation arbeitet, arbeitet mit einem unvollständigen Bild. Architekturentscheidungen werden auf Basis dessen getroffen, was das Bauteil zu können scheint — nicht was es tatsächlich kann.

Was sich tun lässt

In der Designphase: Definieren Sie die Hardware-Schnittstellenverträge, bevor Sie Bauteile auswählen. Das zwingt dazu, über die Anforderungen an das Bauteil nachzudenken — nicht über einen bestimmten Chip.

Bereits in der Produktion: Führen Sie ein architektonisches Abhängigkeits-Audit durch. Kartieren Sie jede Stelle im Code, an der herstellerspezifische APIs, Typen oder Konstanten auftauchen. Diese Karte zeigt Ihr Abhängigkeitsrisiko. Priorisieren Sie die kritischsten Stellen — dort, wo ein Wechsel am meisten Neuentwicklung erfordern würde — und bauen Sie schrittweise Abstraktionsschichten ein.

Das Ziel ist nicht, chinesische Lieferanten zu eliminieren. Für die meisten Hardware-Unternehmen ist das weder realistisch noch sinnvoll. Das Ziel ist, dass Ihre Architekturentscheidungen Sie nicht zum Gefangenen der Roadmap, der Preispolitik oder der geopolitischen Lage eines einzelnen Lieferanten machen.

Das ist ein Architekturproblem. Und es hat eine architektonische Lösung.