Wie Systemarchitektur die Lieferantenflexibilität bestimmt

Einleitung

Wenn Unternehmen über Lieferantenflexibilität sprechen, setzen sie oft am falschen Punkt an. Sie reden über Preisverhandlungen, Dual Sourcing, Rahmenverträge, Lieferzeiten, Qualifizierungsstatus und die Frage, ob ein zweiter Lieferant schnell genug aufgebaut werden kann, um die Produktion abzusichern. All das ist relevant. Aber wenn ein Unternehmen diese Fragen stellt, ist ein Großteil der Antwort längst anderswo festgelegt worden. In vielen Fällen ist Lieferantenflexibilität kein Einkaufsergebnis. Sie ist ein Architekturergebnis.

Der Grund: Jede Systemarchitektur definiert stillschweigend das Feld möglicher Lieferanten. Sie bestimmt, welche Komponenten technisch kompatibel sind, welche Anbieter realistisch in das Produkt integriert werden können, welche Software-Stacks unterstützt werden, welche Teams das System warten können, welche Zertifizierungspfade gangbar bleiben und wie teuer eine spätere Kursänderung wird. Ein Unternehmen glaubt vielleicht, den "besten" Controller, die "beste" Kamera, das "beste" Compute-Modul oder den "besten" Firmware-Stack für die heutigen Anforderungen zu wählen. In Wirklichkeit wählt es oft ein System von Einschränkungen, das seine Lieferantenoptionen auf Jahre prägen wird.

Das wird besonders relevant bei modernen Industrie- und Edge-KI-Systemen, in denen technische Entscheidungen zunehmend geschichtet sind: Compute-Hardware, Deployment-Topologie, Steuerungsarchitektur, Kommunikationsprotokolle, Betriebssysteme, Laufzeitumgebungen, KI-Frameworks, Update-Mechanismen, Datenhoheitsmodelle, Compliance-Anforderungen und Wartungsmodelle greifen alle ineinander. Lock-in entsteht nicht mehr nur, wenn ein Einkäufer einen Exklusivvertrag unterschreibt. Er entsteht, wenn die Architektur alternative Lieferanten technisch, wirtschaftlich oder organisatorisch unrealistisch macht.

Hardware-Architektur

Eine der sichtbarsten Formen, wie Systemarchitektur die Lieferantenflexibilität prägt, ist die Hardware-Wahl. Jede Hardware-Entscheidung bringt Annahmen über Schnittstellen, Software-Support, Kalibrierung, Steuerungslogik, thermisches Design, Zertifizierung und Wartbarkeit mit sich. Deshalb kann ein Bauteil, das beim Sourcing austauschbar erscheint, später tief in die Gesamtarchitektur eingebettet sein.

Compute-Hardware ist ein besonders klares Beispiel. Ein Unternehmen, das Machine Vision oder Edge-Inferenz aufbaut, kann sich für ein GPU-basiertes Design, ein FPGA-basiertes Design, einen dedizierten NPU, ein reines CPU-System oder bei sehr hohen Stückzahlen einen Custom-ASIC entscheiden. Auf den ersten Blick sieht das nach einer Performance-Entscheidung aus. In Wirklichkeit verändert jede Option die Lieferantenlandschaft. Eine GPU-zentrische Architektur zieht ein Unternehmen typischerweise in Richtung einer schmalen Gruppe von Anbietern mit starkem Software-Support, passenden thermischen Hüllen und Entwicklern, die das Ökosystem kennen. Ein Design rund um ein NVIDIA-Edge-Modul mag technisch leistungsfähig und einfach zu prototypisieren sein, koppelt aber die Hardware-Beschaffung an eine spezifische Software-Umgebung, spezifische Treiber, spezifische Optimierungstools und ein spezifisches Entwickler-Skillset. Ein FPGA-lastiges Design eröffnet dagegen Möglichkeiten für deterministische, latenzarme Verarbeitung, reduziert aber den verfügbaren Lieferantenpool auf Unternehmen, die kompatible IP, Toolchains, Boards und Engineering-Expertise liefern können.

Dieselbe Logik gilt weit über Compute hinaus. In optischen Systemen mag ein Objektiv oder optisches Modul wie eine Sourcing-Entscheidung aussehen, bindet in der Praxis aber das Gesamtsystem an bestimmte Montagegeometrien, Verzeichnungscharakteristiken, Kalibrierverfahren, Beleuchtungsannahmen und Bildverarbeitungsparameter. In der Industrieautomation ist eine SPS nicht nur ein Controller — sie zieht typischerweise ein ganzes Ökosystem aus Engineering-Tools, I/O-Modulen, Sicherheitskonzepten, Feldbus-Konventionen und Integratoren nach sich.

Ich habe das sehr direkt in einem Hochgeschwindigkeits-Bildverarbeitungsprojekt erlebt. Früh waren GPUs bereits als leistungsfähige Plattformen für Bildverarbeitung und KI-Workloads im Kommen, aber für unseren Anwendungsfall waren Latenz, Durchsatz sowie Energie- und Kosteneffizienz die entscheidenden Kriterien. Auf diesen Dimensionen sahen programmierbare oder maßgeschneiderte Hardware wie FPGAs — und prinzipiell ASICs — zunächst deutlich attraktiver aus als GPUs. Die Verarbeitungskette enthielt zudem Operationen auf Basis endlicher Körperarithmetik, die nicht natürlich zum GPU-Modell passten.

Was die Entscheidung änderte, war nicht die abstrakte Logik der Architektur, sondern die Geschwindigkeit, mit der sich der umgebende Markt entwickelte. Während der Implementierung verbesserte sich NVIDIAs GPU-Plattform so weit, dass sie für den Workload in Frage kam. Ebenso wichtig: NVIDIAs Software-Stack reduzierte den Entwicklungsaufwand im Vergleich zum FPGA-Pfad so dramatisch, dass sich der Trade-off verschob. Wir wechselten letztlich mittendrin. Damit akzeptierten wir eine deutlich stärkere Abhängigkeit von NVIDIA-Hardware und -Tooling. Portablere Alternativen wie OpenCL existierten, aber in dieser Situation überwogen die Gewinne bei Performance und Entwicklungsgeschwindigkeit die Kosten des engeren Vendor-Lock-in.

Die breitere Erkenntnis: Hardware erzeugt Lock-in nicht nur durch das Bauteil selbst. Sie erzeugt ihn durch die Schnittstellen drumherum, das Software-Ökosystem, den Kalibrierungs- und Validierungsaufwand, das benötigte Engineering-Talent und die Art, wie sich der Markt über die Zeit weiterentwickelt. In vielen Fällen ist ein Vendor-Lock akzeptabel — aber er sollte auf einer bewussten Entscheidung unter Abwägung der Trade-offs basieren, nicht versehentlich entstehen.

Deployment-Topologie

Der Deployment-Standort ist eine weitere architektonische Dimension, die die Lieferantenflexibilität leise formt. Die Entscheidung, ob Compute am Edge, auf einem zentralen Server oder in einer Hybrid-Architektur lebt, wird oft als Latenz- oder Bandbreitenfrage dargestellt. Aber sie definiert auch, welche Lieferanten überhaupt in Frage kommen. Muss Inferenz auf dem Gerät stattfinden, weil Latenz kritisch ist, Konnektivität unzuverlässig oder Daten den Standort nicht verlassen dürfen, drängt die Architektur in Richtung robuster Embedded-Compute-Anbieter, industrieller Thermallösungen, spezialisierter Kameraprozessoren und On-Device-Deployment-Tooling. In der Praxis ist der Wechsel später nicht einfach ein "Verschieben von Workloads" — er kann ein vollständiges Redesign von Datenpipelines, Synchronisationslogik, Bandbreitenannahmen und Geräte-Provisioning erfordern.

Software- und Firmware-Lock-in

Viele Systeme werden nicht deshalb abhängig, weil die physische Komponente selbst unersetzlich ist, sondern weil die umgebende Firmware, das SDK und das Software-Ökosystem tief in das Produkt eingebettet werden. Ein klassisches Beispiel ist ein System, das eng um einen herstellerspezifischen GPU-Stack herum entworfen wurde. Selbst wenn ein anderer Anbieter theoretisch gleichwertige Hardware-Performance liefern könnte, können die Kosten für die Migration optimierter Kernel, das Umschreiben der Deployment-Logik, die Umschulung von Entwicklern und die erneute Validierung so hoch sein, dass der zweite Lieferant kommerziell unrealistisch ist. Kompatibilität existiert auf dem Papier; Lock-in existiert im Code.

Ich habe dasselbe Muster bei einem Barcode-Scanner-Integrationsprojekt erlebt. Auf Sourcing-Ebene erschien der Markt hochflexibel: Chinesische Anbieter boten eine breite Palette von OEM- und White-Label-Scannern zu wettbewerbsfähigen Preisen. Das Problem war nicht das physische Gerät, sondern die Art, wie die Software darum herum geschrieben worden war. Die bestehende Implementierung hatte das Datenformat einer spezifischen Scanner-Firmware effektiv in die breitere Anwendungslogik hineinkodiert. Die Lösung war, die Architektur so umzubauen, dass die Dekodierung des gerätespezifischen Protokolls ein separates Software-Modul wurde, während Workflow und Zustandsmanagement unabhängig vom konkreten Scanner gehandhabt wurden. Der Lock-in war nicht vom Scanner erzeugt worden. Er war von der Software-Architektur drumherum erzeugt worden.

Steuerungsarchitektur

In industriellen Umgebungen hat die Wahl zwischen einem SPS-zentrierten Design, einem Embedded-Steuerungssystem oder einem Hybridmodell enorme Auswirkungen auf die Lieferantenflexibilität. Eine SPS-basierte Architektur bietet Robustheit, Wartbarkeit und Zertifizierungsvorteile, bindet das System aber oft an die Programmierumgebung, das I/O-Ökosystem, die Sicherheitsmodule und das Integratoren-Netzwerk eines Herstellers. Standards wie IEC 61131-3 erzeugen den Anschein von Portabilität, doch jeder, der eine substanzielle Siemens-, Rockwell- oder Beckhoff-Installation migriert hat, weiß, wie viel praktische Abhängigkeit in herstellerspezifischem Tooling, Bibliotheken und Integrationsannahmen auf Anlagenebene steckt.

Protokolle und Ökosysteme

Kommunikations- und Feldbus-Entscheidungen sind oft weniger restriktiv als proprietäre Schnittstellen, weil Standards wie PROFINET, EtherCAT, Modbus, CAN und OPC UA breit eingesetzt werden und teilweise explizit für herstellerübergreifende Interoperabilität konzipiert sind. Diese Offenheit ist real und wertvoll. Aber in der Praxis übersetzt sich Interoperabilität auf Protokollebene nicht automatisch in volle Lieferantenflexibilität auf Systemebene. Offene Standards reduzieren oft Vendor-Lock-in, beseitigen aber nicht Ökosystem-Lock-in.

Betriebssysteme und Laufzeitumgebungen

Die Wahl des Betriebssystems und der Laufzeitumgebung hat ähnliche Auswirkungen. Linux, ein RTOS, ein Bare-Metal-Ansatz, eine SPS-Laufzeit oder eine herstellerbereitgestellte Appliance-Umgebung bestimmen nicht nur das technische Verhalten, sondern auch die Austauschbarkeit von Lieferanten. Ich habe das wiederholt bei Geräten erlebt, die ursprünglich für wissenschaftliche oder Laborumgebungen entwickelt wurden. Die Hardware war technisch attraktiv, aber der Lieferant bot nur robusten Treiber-Support für Windows. Das mag im Labor akzeptabel sein, wird aber zum strategischen Problem, wenn das Zielsystem auf Linux aufbaut — wie es bei rechenintensiven industriellen oder Embedded-Umgebungen häufig der Fall ist.

KI-Frameworks und Inferenz-Tooling

Bei KI-fähigen Systemen bilden Modell-Framework und Inferenz-Tooling eine weitere Lock-in-Achse. Teams unterschätzen häufig, wie viel Lieferantenabhängigkeit entsteht, wenn Modelle für eine bestimmte Laufzeit optimiert statt portabel gehalten werden. Ein Unternehmen beginnt vielleicht mit PyTorch oder TensorFlow für die Entwicklung und optimiert dann das Deployment mit einem herstellerspezifischen Stack wie TensorRT. Ab diesem Moment beginnt die Architektur, eine engere Gruppe von Hardware-Lieferanten zu begünstigen. Ein offenes Austauschformat wie ONNX mag theoretisch Portabilität bewahren, aber in der Praxis driften viele Deployments in Richtung herstellerspezifischer Operatoren, Quantisierungspfade und Validierungsannahmen.

Deployment- und Update-Modelle

Update- und Deployment-Modelle prägen die Lieferantenflexibilität stärker, als vielen Organisationen bewusst ist. Ein System mit Over-the-Air-Updates, Remote-Observability, containerisiertem Rollout und strukturiertem Fleet-Management kann Lieferantenwechsel leichter verkraften, weil die Software-Schicht einfacher anzupassen und neu auszurollen ist. Operationale Architektur ist Teil der Lieferantenflexibilität.

Datenhoheit

Datenarchitektur und -hoheit fügen eine weitere strategische Dimension hinzu. Die Entscheidung, wo Rohdaten liegen, wie sie strukturiert sind, welche Metadaten erhalten bleiben und wer Zugriff hat, beeinflusst die künftige Verhandlungsposition stärker als viele Teams erwarten. Wenn eine Vendor-Appliance Bilder intern verarbeitet und nur High-Level-Ergebnisse ausgibt, kann das Unternehmen nicht nur bei der Hardware, sondern auch bei den Daten abhängig werden, die es für Modellverbesserungen, Edge-Case-Validierung oder die Qualifizierung von Alternativen braucht. Daten-Lock-in ist bei KI-Systemen besonders wichtig, weil künftige Leistungsverbesserungen oft weniger von der ursprünglichen Hardware abhängen als von der Fähigkeit, operative Daten zu nutzen und wiederzuverwenden.

Integration und Modularität

Hardware-Modularität versus Integration ist eine weitere prägende Entscheidung. Integrierte Systeme können elegant, kompakt und einfacher zu zertifizieren sein. Aber Integration komprimiert oft mehrere Lieferantenentscheidungen in eine Box. Wird Performance, Preis oder Verfügbarkeit problematisch, muss möglicherweise die gesamte Einheit ersetzt werden statt einer Teilkomponente. Eine modulare Architektur kann Flexibilität bewahren, indem sie Kamera, Objektiv, Compute, I/O, Netzteil und Gehäuse trennt. Der Trade-off ist natürlich, dass Modularität den Integrationsaufwand erhöht. Aber genau darum geht es: Lieferantenflexibilität ist oft eine direkte Folge davon, wie viel Modularität die Architektur am Anfang bewahrt hat.

Leistung, Thermik und Timing

Leistungs- und Thermik-Constraints erzeugen Lock-in auf subtilere Weise. Ist ein Produkt einmal um ein bestimmtes Leistungsbudget, eine Kühlstrategie und einen physischen Formfaktor herum entworfen, verschwinden viele theoretisch attraktive Lieferanten. Ein System für passiv gekühlten, stromsparenden Betrieb kann nicht einfach ein Hochleistungsmodul einsetzen, ohne Gehäuse, Spannungsregelung und Umweltzertifizierungen neu zu designen. Die Architektur wählt nicht nur eine aktuelle Komponente; sie wählt die Klasse künftiger Substitute. Frühe mechanische und thermische Entscheidungen werden deshalb oft zu verkleideten Supply-Chain-Entscheidungen.

Marktentwicklung

Lieferanten-Lock-in wird oft so beschrieben, als entstehe er in einem einzigen Moment. In der Praxis ist er meist dynamischer. Die Architektur setzt die Anfangsrichtung, aber der Grad des Lock-in wird oft später durch die Marktentwicklung um die gewählte Plattform herum verstärkt.

Das ist besonders sichtbar bei Accelerated Computing. Ein Team wählt vielleicht GPU-basierte Inferenz, weil die Hardware verfügbar und leistungsfähig genug ist, aber was die Abhängigkeit über die Zeit deutlich stärker macht, ist der umgebende Software-Stack. NVIDIAs TensorRT ist nicht nur eine Bibliothek; es ist Teil eines breiteren Deployment-Ökosystems. Sobald ein Produktteam auf diese Optimierungen, Workflows und Laufzeitannahmen angewiesen ist, steigen die praktischen Wechselkosten erheblich.

Eine ähnliche Dynamik existiert außerhalb von KI-Laufzeiten. In der industriellen Vernetzung kann ein Protokoll wie EtherCAT als technische Wahl für deterministische Kommunikation beginnen, aber Lock-in wächst, wenn das umgebende Ökosystem sich verdichtet. Entscheidend ist in all diesen Fällen: Lieferantenflexibilität wird nicht nur davon geprägt, was heute technisch kompatibel ist, sondern davon, welche Ökosysteme sich weiter verbessern, Entwickler anziehen und Integrationsvorteile anhäufen. Eine Plattform wird nicht schwerer zu verlassen, weil Alternativen verschwinden, sondern weil die wirtschaftliche und organisatorische Strafe für das Verlassen steigt.

Deshalb kann Lieferantenflexibilität nicht nur zum Zeitpunkt des Designs bewertet werden. Sie muss auch gegen wahrscheinliche Marktentwicklungen geprüft werden. Gute Architektur fragt nicht nur, welche Lieferanten jetzt kompatibel sind. Sie fragt, welche Ökosysteme in Zukunft die besten Optionen bieten werden — im Bewusstsein, dass diese Einschätzungen sich als falsch erweisen können.

Kompetenzen und Wartungsmodelle

Wartungs- und Kompetenzmodelle sind ebenso wichtig. Zwei Architekturen mögen auf dem Papier technisch austauschbar sein, aber völlig unterschiedliche organisatorische Konsequenzen haben. Eine SPS-zentrische Maschine kann von Anlagentechnikern und bestehenden Automatisierungspartnern gewartet werden, während ein Linux-basiertes Embedded-System Software-Ingenieure, DevOps-Fähigkeiten und ein anderes Servicemodell erfordert. Je stärker die Architektur eines Unternehmens von seltenen oder herstellerspezifischen Kompetenzen abhängt, desto mehr Lieferantenflexibilität geht verloren. Lock-in betrifft nicht nur Komponenten. Er betrifft Kompetenz.

Darüber hinaus habe ich wiederholt erlebt, dass Ingenieure eine starke Präferenz für Tech-Stacks und Geräte haben, mit denen sie vertraut sind — selbst wenn dieser Stack oder dieses Gerät für das aktuelle Problem nicht (mehr) geeignet ist. Das ist oft eine weitere versteckte Quelle langfristiger struktureller Lock-ins bei bestimmten Lieferanten und Technologien.

Geopolitik und Compliance

Geopolitische Faktoren und regulatorische Anforderungen bilden eine weitere Dimension, die zunehmend an Bedeutung gewinnt. Die Wahl eines chinesischen SoC-Anbieters, eines US-kontrollierten GPU-Stacks oder eines regionsspezifischen Industrielieferanten ist nicht nur eine Sourcing-Entscheidung. Sie erzeugt Exposure gegenüber Exportkontrollen, Sanktionsrisiken, Lieferzeit-Volatilität, Zertifizierungsreibung und Support-Modell-Divergenz.

Zertifizierungsanforderungen fügen eine weitere Abhängigkeitsschicht hinzu, die viele Unternehmen bis überraschend spät im Produktzyklus unterschätzen. In der EU benötigen viele elektronische Produkte CE-Konformität. In China erfordern Produkte unter dem relevanten Katalog eine CCC-Zertifizierung. In den USA ist eine Sicherheitszertifizierung wie UL oft nicht nur eine technische Präferenz, sondern eine praktische Markterwartung. Die Konsequenz: Sobald eine Komponente in einem Produkt qualifiziert ist, das bereits getestet oder für den Launch vorbereitet wird, kann ein späterer Lieferantenwechsel neue Tests, Dokumentationsaktualisierungen, Verzögerungen und Zusatzkosten auslösen.

Gerade Startups neigen dazu, wenig Geduld für regulatorische und Zertifizierungsanforderungen aufzubringen. Schließlich ist es schon eine Herkulesaufgabe, das erste Produkt zum Laufen zu bringen. Diese Haltung ist verständlich, und in vielen Fällen ist eine Zertifizierung im Prototypenstadium nicht erforderlich. Aber diese Faktoren sollten nicht völlig ignoriert werden. Sonst kann man sich in einer Situation wiederfinden, in der man nach Jahren Arbeit ein technisch fertiges Produkt hat, das aber komplett umgebaut werden muss, bevor es legal auf den Markt darf.

Die Architektur bestimmt, welche Teile des Systems zertifizierungskritisch werden. Wird diese Grenze nachlässig gezogen, kann ein Unternehmen eine ansonsten austauschbare Lieferantenentscheidung in ein hochreguliertes Änderungsereignis verwandeln. Gute Architektur isoliert zertifizierungssensitive Funktionen wo möglich und schützt den Rest des Systems vor unnötigen Requalifizierungslasten.

Wie Lock-in sich aufbaut

Zusammengenommen offenbaren diese Dimensionen eine breitere Wahrheit: Lock-in ist selten das Ergebnis einer einzigen schlechten Entscheidung. Er entsteht meist aus dem Zusammenspiel vieler vernünftiger Einzelentscheidungen, die nie als Ganzes betrachtet wurden. Ein Team wählt eine GPU für schnelles Prototyping. Es übernimmt die Optimierungstools des Herstellers, um Deadlines zu halten. Es deployt am Edge, weil die Konnektivität nicht perfekt ist. Es integriert eng mit einem Feldbus, der in der Anlage bereits im Einsatz ist. Es wählt ein geschlossenes Kameramodul, weil es das Gehäusedesign vereinfacht. Jede Entscheidung ist für sich nachvollziehbar. Doch nach zwei Jahren stellt das Unternehmen fest, dass es nicht nur ein Produkt gebaut hat. Es hat einen engen Korridor gebaut, durch den nur noch eine Handvoll Lieferanten passt.

Deshalb muss Lieferantenflexibilität von Anfang an als architektonisches Designziel behandelt werden. Das bedeutet nicht, überall auf maximale Offenheit zu optimieren. In manchen Fällen ist bewusster Lock-in rational. Ein Unternehmen kann die Abhängigkeit von einem führenden Compute-Ökosystem akzeptieren, weil es die Time-to-Market beschleunigt. Der entscheidende Punkt ist nicht, Lock-in um jeden Preis zu vermeiden. Es geht darum zu verstehen, wo er entsteht, warum, und welchen strategischen Preis man dafür zahlt.

Die besten architektonischen Entscheidungen fragen deshalb nicht nur: "Funktioniert diese Komponente?" oder "Ist dieser Anbieter verfügbar?" Sie stellen härtere Fragen: Welche künftigen Lieferanten schließt diese Entscheidung aus? Welche Software-Annahmen erzeugt sie? Welche Kompetenzen müssen wir vorhalten? Welche Datenrechte geben wir ab? Welche Schnittstellen bleiben modular, und welche verschmelzen? Was würde ein Wechsel in zwei Jahren wirklich kosten, wenn sich Preis, Politik, Performance oder Verfügbarkeit ändern?

Unternehmen, die diese Fragen früh stellen, gewinnen weit mehr als Einkaufshebel. Sie gewinnen strategischen Handlungsspielraum. Sie können alternative Lieferanten schneller qualifizieren, aus einer stärkeren Position verhandeln, ihre Produkte mit weniger Reibung weiterentwickeln und sich an veränderte Technologie- und geopolitische Bedingungen anpassen, ohne das gesamte System unter Druck neu zu designen. In diesem Sinne ist Lieferantenflexibilität nichts, was der Einkauf am Ende hinzufügt. Sie ist etwas, das die Architektur am Anfang entweder bewahrt oder zerstört.