Build vs Buy in regulierten Industrien: Wann individuelle Entwicklung die einzige verantwortbare Option ist

Es gibt zwei Arten von Softwareentscheidungen: solche, die Sie später revidieren können, und solche, die die Architektur und Souveränität Ihres Unternehmens auf Jahre festlegen. In sicherheitskritischen oder hochregulierten Umgebungen (Defense, Bahn, Luftfahrt, Fertigung) ist die Frage Build vs Buy selten eine reine Kosten-Nutzen-Rechnung. Sie ist eine Risikoentscheidung über Datenhoheit, Auditierbarkeit, Laufzeitgarantien, Lebenszyklen und Abhängigkeiten. In vielen dieser Umfelder ist maßgeschneiderte Entwicklung nicht Luxus, sondern die einzige verantwortbare Option.

Dieser Artikel ist aus der Perspektive eines Softwarearchitekten geschrieben, der Systeme unter hohen Auflagen baut und betreibt. Ich beschreibe, warum Standardsoftware regelmäßig an regulatorischen und technischen Realitäten scheitert, welche Architektur- und Organisationsmuster wir in der Praxis verwenden, und wie man eine Build-vs-Buy-Entscheidung trifft, die Jahre später noch tragfähig ist.

Problemfelder, die COTS-Software in regulierten Branchen nicht löst

Es geht nicht darum, ob eine Off-the-Shelf-Lösung “gut genug” wirkt. Es geht darum, ob sie die nichtfunktionalen Anforderungen Ihrer Domäne überhaupt modelliert. Typische Stolpersteine:

  • Datenhoheit und Jurisdiktion: Wenn personenbezogene oder betriebsgeheime Daten Ihre Umgebung nicht verlassen dürfen, wenn On-Premise Pflicht ist und Cloud-Jurisdiktion (z. B. extraterritoriale Zugriffe) ausgeschlossen werden muss, sind viele SaaS-Angebote schlicht nicht zulassungsfähig. DSGVO-Konformität, Datenresidenz, Betriebsführung durch Sie selbst – diese Anforderungen sind mit einem fremdbetriebenen Multi-Tenant-Stack schwer vereinbar.
  • Determinismus und Laufzeitgarantien: Visuelle Qualitätskontrolle, Zugleit- und Flottenintelligenz, Wartungsassistenz – all das hat harte Latenz- und Verfügbarkeitsgrenzen. “Best effort” in einer Shared Cloud, variierende Latenzen durch Internetpfade und Remote-Inferenz sind hier ein Ausschlusskriterium. Offline-Fähigkeit ist keine “nice to have”, sondern Betriebsbedingung.
  • Nachvollziehbarkeit und Zertifizierbarkeit: In bahn- oder luftfahrtnahen Anwendungen zählt lückenlose Traceability: Anforderungen → Design → Code → Test → Release. Opaque Blackbox-Komponenten, proprietäre ML-APIs ohne Einblick in Modellversionen, fehlende SBOMs (Software Bill of Materials) und ungeklärte Update-Mechanismen sind red flags.
  • Lieferketten- und Lebenszyklusrisiken: Industrielle Plattformen leben 10–20 Jahre. Forced Upgrades, Vendor Lock-in, das Ende einer Produktlinie oder Preismodelländerungen sind nicht nur lästig – sie gefährden die Betriebserlaubnis. Sie brauchen langfristige Update- und Patch-Strategien unter Ihrer Kontrolle.
  • Industrienahe Integration: Feldbusse, OPC UA, Safety-Protokolle, Edge-Gateways mit intermittierender Konnektivität – viele COTS-Produkte bilden die industrielle Peripherie nur oberflächlich ab. Die Folge sind fragile Integrationen, die in der Realität scheitern.
  • ML/LLM-Governance: Wer KI produktiv betreibt, muss Modelle, Datensätze, Prompts, Evaluationsmetriken versionieren, Freigaben dokumentieren und Betriebsmetriken auditierbar machen. Ein “Wir rufen eine API an” genügt nicht, wenn Prüf- und Nachweispflichten gelten.

Warum Standardsoftware häufig teuer wird, wenn sie scheinbar günstig startet

COTS ist verlockend: kurze Beschaffungszyklen, vorhandene Features, Demo in Woche eins. Der Preis kommt später:

  • Anpassung wird zur Zweitentwicklung: Je näher Sie COTS an Ihre Domäne biegen, desto mehr bauen Sie daneben: eigene Datenpipelines, Export/Import, Shadow-Datenhaltung, Scripte. Irgendwann betreiben Sie zwei Plattformen.
  • Update-Kadenz vs. Validierung: Wenn Ihr Validierungszyklus Monate dauert, aber der Anbieter monatliche Major-Updates durchdrückt, kollidiert das mit Ihrem Freigabeprozess. Sie frieren ein – und zahlen dafür mit technischem und organisatorischem Schuldendruck.
  • Lizenz- und Betriebsrisiken: Verbrauchsbasierte Preismodelle, Egress-Kosten, tokenbasierte LLM-Inferenz – all das verlagert Risiko in den Betrieb. Ihr Sizing wird zum Finanzwetterbericht.
  • Telemetrie und Datenabfluss: COTS-Produkte senden gerne Telemetrie. In Umgebungen mit Geheimhaltungsanforderungen ist das ein No-Go. Selbst “abschaltbare” Telemetrie muss auditierbar und dauerhaft unter Ihrer Kontrolle sein.

Ein Entscheidungsrahmen: Wann Build alternativlos ist

Individuelle Entwicklung ist kein Selbstzweck. Sie ist die vernünftige Antwort, wenn eines oder mehrere der folgenden Kriterien erfüllt sind:

  • Jurisdiktion und Souveränität:
  • On-Premise-Pflicht, Betrieb in Ihrem Rechenzentrum oder an der Edge
  • Ausschluss ausländischer Jurisdiktionen und Fremdbetrieb
  • Vollständige Kontrolle über Datenflüsse, Telemetrie und Logs
  • Harte nichtfunktionale Anforderungen:
  • Harte Latenzgrenzen und deterministische Reaktionszeiten
  • Offline- oder Disconnected-Betrieb als Norm
  • Reproduzierbares Verhalten (z. B. in sicherheitsnahen Assistenzsystemen)
  • Regulatorik und Zertifizierbarkeit:
  • Nachvollziehbare Toolchain (Build, Test, Freigabe)
  • Lückenlose Traceability und Änderungsmanagement
  • Abgesicherte Lieferkette (SBOM, signierte Artefakte, Reproduzierbarkeit)
  • Domänenspezifische Integration:
  • Feldnahe Protokolle und Sensorik
  • Enge MES/ERP-Kopplung unter ACID- oder Echtzeitauflagen
  • Edge-zu-Zentral-Topologien mit intermittierender Konnektivität
  • KI-Governance als Pflicht:
  • Modelle dürfen das Firmengelände nicht verlassen
  • On-Prem-Training, -Evaluierung und -Inferenz
  • Auditierbare Prompt- und Tool-Nutzung bei LLM-Agenten

Architekturmuster für souveräne, maßgeschneiderte Systeme

Was bedeutet “Build” konkret? Nicht Microservices um der Microservices willen, sondern eine Architektur, die Ihre Zwänge abbildet. Bewährte Muster:

  • Edge- und On-Prem-first:
  • Trennen Sie Kontroll- und Datenebene. Der Control-Plane-Stack (Orchestrierung, Konfiguration, Secrets) läuft unter Ihrer PKI. Datenpfade sind minimal und explizit.
  • Air-gapped Betriebsmodi ermöglichen Builds und Deployments ohne Internetzugang. Artefakte werden signiert und über geprüfte Stufen migriert.
  • Sicherheitsfundament:
  • Zero-Trust-Netzwerke, mTLS, interne Root-CA
  • Hardware-gebundene Identitäten (TPM/SE) und Remote Attestation für Edge-Geräte
  • Least Privilege als Default – auch für interne Dienste
  • Richtige Granularität:
  • Für sicherheitsnahe Kerne ist ein modularer Monolith oft die bessere Wahl: weniger verteilte Komplexität, einfacher zu validieren, klare Laufzeitprofile.
  • Periphere Funktionen (Berichte, Synchronisation, Analytik) als entkoppelte Services, bevorzugt ereignisgetrieben. So bleibt das Sicherheitskritische überschaubar.