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

Aus Sicht eines Softwarearchitekten in defense-nahen und industriellen Umfeldern gibt es eine unangenehme Wahrheit: Der reflexhafte Griff zu Off‑the‑Shelf-Produkten und Public-Cloud-APIs scheitert dort, wo Datenhoheit, Nachvollziehbarkeit und deterministische Betriebsbedingungen nicht verhandelbar sind. Nicht, weil Standardsoftware per se schlecht wäre, sondern weil ihre impliziten Annahmen (multitenant, internet‑verbunden, „best effort“‑SLA, black‑box‑Komponenten) den Sicherheits- und Audit-Anforderungen widersprechen.

Dieser Artikel ist kein Plädoyer, grundsätzlich alles selbst zu bauen. Er legt einen technischen Entscheidungsrahmen dar, anhand dessen Sie die „Build vs Buy“-Frage diszipliniert beantworten können – inklusive konkreter Architekturmuster, Risikobetrachtung, Kostenkategorien und Migrationspfaden. Er adressiert insbesondere CTOs, VP Engineering und Leiter Digitalisierung in DACH, die in sicherheitskritischen oder stark regulierten Domänen entwickeln.

Problem zuerst: Wo „Buy“ systemisch scheitert

In den folgenden Problemklassen kollidiert der „Buy“-Ansatz regelmäßig mit nicht verhandelbaren Randbedingungen:

  • Datenhoheit und Betriebsmodell:
  • Geforderte On‑Prem- oder Edge‑Bereitstellung, inklusive Air‑Gap oder eingeschränkter Konnektivität.
  • Verbot von Datenabflüssen in US‑Clouds oder unklare Unterauftragnehmerketten.
  • Notwendigkeit, Telemetrie und Nutzungsdaten lokal zu halten bzw. granulär zu kontrollieren.
  • Auditierbarkeit und Nachvollziehbarkeit:
  • Nachweispflichten gegenüber Audit- und Zertifizierungsstellen.
  • Erklärbarkeit von Entscheidungen, insbesondere bei ML/LLM‑Einsatz: Wer hat wann mit welcher Konfiguration welches Ergebnis erzeugt?
  • Reproduzierbare Builds, SBOM, formale Freigaben.
  • Determinismus, Latenz, Robustheit:
  • Harte Latenzbudgets in Regelkreisen oder Bildverarbeitung an der Linie.
  • Fehlermodi müssen gezielt provozier- und testbar sein.
  • Degradationsfähigkeit und „fail‑safe“ Verhalten sind erforderlich.
  • Integrations- und Lebenszyklusdominanz:
  • 80% der Arbeit liegen in der Domänenintegration: Feldbusse, proprietäre Protokolle, Sicherheitszonen, Altdatenmodelle.
  • Notwendigkeit, über 10+ Jahre kontrolliert weiterzuentwickeln, Komponenten austauschen zu können und die Ownership zu behalten.

Sobald zwei oder mehr dieser Punkte „hart“ sind, wird Buy im Kernsystem riskant. „Buy“ kann weiterhin sinnvoll sein – als Commodity‑Baustein an den Rändern. Aber der Systemkern verlangt Architekturhoheit.

Ein Entscheidungsrahmen: Nicht Verhandelbares vs. Variablen

Bevor Sie evaluieren, ob ein Produkt X Ihr Problem löst, definieren Sie die nicht verhandelbaren Systemattribute:

  • Betriebsumgebung:
  • On‑Prem/Edge, Air‑Gap, Offline‑Betrieb, deterministische Ressourcen.
  • Patch- und Updatefenster, Wartungsfenster, Rollback‑Fähigkeit.
  • Governance und Compliance:
  • Vollständige Nachvollziehbarkeit aller Änderungen (Konfiguration, Modelle, Datenpfade).
  • Prüfbarkeit ohne Internetzugang.
  • Wiederholbarkeit: Build‑Reproduzierbarkeit, Artefaktkontrolle, SBOM.
  • Datenhoheit:
  • Daten bleiben im Haus; Telemetrie nur nach definierten Policies.
  • Kein Vendor‑Lock‑in auf proprietäre Datenformate.
  • Sicherheitsarchitektur:
  • Zonenmodell, minimaler Vertrauensanker, Härtung, Secrets‑Handling on‑prem.
  • Kein Zwang zu externen IdPs oder managed Services außerhalb der Kontrolle.

Danach erst bewerten Sie die Variablen:

  • Time‑to‑Value: Wie kritisch ist ein schneller Start, und was ist der Preis dafür im Lebenszyklus?
  • Differenzierung: Ist das, was Sie bauen, wettbewerbsdifferenzierend? Kernfunktionen verdienen Ownership.
  • Teamfähigkeit: Können Sie den Betrieb und die Weiterentwicklung stemmen? Wenn ja, sind Build‑Kosten planbar.
  • Evolvierbarkeit: Wie oft erwarten Sie Anforderungswechsel? Black‑box‑Produkte sind hier träge.

Ein pragmatischer Algorithmus

  • Checkliste „Nicht verhandelbar“ abhaken. Ein „Nein“ bedeutet: Buy nur als Randkomponente.
  • System in „Kern“ und „Peripherie“ zerlegen.
  • Für den Kern: Build, es sei denn, es existiert ein COTS‑Baustein, den Sie unter Ihre Governance zwingen können (on‑prem, quelloffen oder mit Escrow, einschränkbare Telemetrie).
  • Für die Peripherie: Buy, solange Schnittstellen stabil und austauschbar sind.
  • Beschließen Sie technische Ownership explizit: Wer ist langfristig für Architektur, Qualitätssicherung und Betrieb verantwortlich?

Architekturmuster: Wie Build und Buy sauber kombinieren

1) Sicherheitskern und austauschbare Ränder

  • Sicherheitskern:

  • Domänenlogik, Safety‑Cases, Datenhaltung, Identitäten.

  • On‑Prem‑komponiert, minimalistisch, streng versioniert.

  • Ränder:

  • UI, Reporting, einzelne Algorithmen, Commodity‑Dienste.

  • Können gekauft, aber über stabile Ports/Adapter entkoppelt werden.

  • Contract‑Tests sichern Schnittstellen; Escrow oder Open‑Source‑Lizenzen verhindern Vendor‑Lock.

2) Control Plane vs. Data Plane

  • Control Plane:

  • Konfiguration, Orchestrierung, Policies, Audits.

  • Vollständig unter Ihrer Kontrolle, mit unveränderlichem Audit‑Log.

  • Data Plane:

  • Datenverarbeitung, inferencing, Echtzeitpfade.

  • Frei von Netzwerkabhängigkeiten, latenz- und determinismusoptimiert.

3) Strangler‑Fig‑Pattern für Legacy‑Migration

  • Vor das Altsystem wird eine Fassade gesetzt, die neue Schnittstellen bereitstellt.

  • Funktionalitäten werden inkrementell herausgelöst, parallel betrieben, durch Metriken und Shadow‑Traffic abgesichert.

  • Rückfallmechanismen per Feature‑Flag, bis das Altsystem stranguliert ist.

4) On‑Prem‑MLOps/LLMOps ohne Cloudabhängigkeit

  • Modelle, Tokenizer, Embeddings lokal versionieren.

  • Reproducible Training/Finetuning via Container‑Builds; deterministische Seeds.

  • Feature/Vector Stores on‑prem, Tresor für Artefakte und Schlüssel.

  • Observability mit vollständigen Inferenz‑Traces, Prompt‑/Kontext‑Historie, Policy‑Durchsetzung und Audit‑Export – ohne externe Telemetrie.

5) Air‑Gap‑Updates und Offline‑Governance

  • Signierte Update‑Bundles (Software, Modelle, Policies), transportiert via Wechseldatenträger.

  • Zwei‑Schlüssel‑Freigabe, Write‑Once‑Read‑Many‑Artefaktarchive.

  • Offline‑Prüfberichte, die Auditoren ohne Internetzugang nachvollziehen können.

Szenarien aus der Praxis

  • Fertigung: Visuelle Qualitätskontrolle an der Linie mit harten Taktzeiten.
  • Kernanforderungen: deterministische Latenz < X ms, robuste Inferenz ohne Internet, Nachvollziehbarkeit der ML‑Entscheidungspfade.
  • Architektur: Edge‑Inferencing auf IPCs, lokaler Model‑Cache, konfektionierte GPU‑Treiberstände, Schattenmodus für neue Modelle, Rollback in <1 Minute.