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

Die meisten Diskussionen zu Build vs Buy beginnen mit Budget und Lieferzeit. In sicherheitskritischen und regulierten Domänen sind das Nebenschauplätze. Das eigentliche Primat ist technisch: Welche Systemeigenschaften müssen invariant sein – auch dann, wenn sich Lieferanten, Technologien oder regulatorische Anforderungen ändern? Genau daran scheitern Off-the-Shelf-Lösungen regelmäßig: Sie liefern Funktionen, aber nicht die nötigen Invarianten.

Ich schreibe das aus der Perspektive eines Softwarearchitekten, der Systeme im Defense- und Luftfahrtumfeld, in Produktions-IT und Bahn gebaut und in Betrieb gesehen hat. Die zentrale Beobachtung: In bestimmten Problemklassen ist Buy nicht nur suboptimal – es erzeugt aktiv technische Schulden, die später Teureres und Riskanteres erzwingen. Dann ist Build keine “Luxusentscheidung”, sondern die kostengünstigste und risikominimierende Alternative über die Lebensdauer.

Problemorientierter Einstieg: Wo Off-the-Shelf kollidiert

Es gibt fünf wiederkehrende technische Konflikte zwischen Standardsoftware und industriellen Anforderungen:

1) Datenhoheit und Isolationsgrad

  • Anforderung: Volle Kontrolle über Datenflüsse, Metadaten, Protokollierung, Identitäten und kryptografische Schlüssel. Häufig Air-Gap oder zumindest strikt segmentierte Netze.

  • Konflikt: SaaS-Modelle binden Sie an externe Datenspeicher, externe Telemetrie und undurchsichtige Betriebsprozesse. Auch “On-Prem-Varianten” führen oft Schattenabhängigkeiten in Updates, Lizenzservern oder Telemetriekanälen ein.

2) Determinismus und Vorhersagbarkeit im Betrieb

  • Anforderung: Reproduzierbare Builds, deterministische Deployments, definierte Latenzbudgets, kontrollierte Downtime-Fenster, planbare Upgrades.

  • Konflikt: Generische Plattformen sind auf Multi-Tenant-Effizienz und Feature Velocity optimiert, nicht auf harte Timeouts in Edge- oder OT-Netzen. Upgrade-Zyklen folgen Anbieter-Roadmaps, nicht Ihrem Wartungsfenster.

3) Lebensdauer und Änderungsautonomie

  • Anforderung: 10–20 Jahre Betrieb, Auditierbarkeit alter Zustände, Migrationsfähigkeit ohne Unterbrechung, Beherrsschbarkeit des technischen Kerns.

  • Konflikt: Roadmap-Drift. APIs und Lizenzmodelle ändern sich, Produkte werden eingestellt oder “umplattformt”. Sie verlieren die Entscheidungsgewalt über kritische Architekturelemente.

4) Integrations- und Domänenbesonderheiten

  • Anforderung: Brücken zwischen sehr alten Protokollen/Systemen und neuen Workloads, Anti-Corruption-Layer, domain-spezifische Datenmodelle.

  • Konflikt: Standardsoftware erzwingt generische Datenmodelle und Integrationspfade, die gerade an den Rändern (OT, SCADA, Sonderfahrzeuge, Feldgeräte) hohe Komplexität verursachen.

5) Governance von lernenden Systemen

  • Anforderung: Nachvollziehbarkeit von Modell-/Prompt-Versionen, Evaluationsmetriken, Audit-Trails, Policies für Agentenaktionen, Daten- und Kontextlokalität.

  • Konflikt: “Schnelle” KI-Integrationen delegieren die kritischen Governance-Punkte an externe APIs und Telemetrie. Das skaliert nicht in regulierten Umgebungen.

Wann Build die einzig rationale Wahl ist

Sie sollten individuelle Entwicklung ernsthaft in Betracht ziehen, wenn mindestens zwei der folgenden Kriterien zutreffen:

  • Harte Daten- und Betriebssouveränität: Betrieb in isolierten Netzbereichen, verpflichtende On-Prem-Anforderungen, kein externer Abfluss von Metadaten/Logs/Key-Material.
  • Deterministische Latenz oder Offline-Betrieb: Edge-Szenarien mit intermittenter Konnektivität, harte Reaktionszeiten, definiertes Degradationsverhalten im Fehlerfall.
  • Domänenspezifische Integrationen: Altsysteme ohne tragfähige Standard-Konnektoren, proprietäre Protokolle oder Geräteschnittstellen, die stabil in ein neues Domänenmodell überführt werden müssen.
  • Lange Lebenszyklen und Revisionssicherheit: Sicherer Betrieb über Jahrzehnte, Nachvollziehbarkeit vergangener Zustände, kontrollierbare Migrationspfade ohne Serviceunterbrechung.
  • Regulatorische Nachweise: Prüffähigkeit von Artefakten, Builds, Testabdeckung, Datenherkunft und -verwendung, inklusive restriktiver Export-/Lieferkettenanforderungen.
  • Agentische/LLM-Workloads unter eigener Governance: Interne Policy-Enforcement, Observability, reproduzierbare Inferenzpfade, keine US-Cloud-Abhängigkeit.

Wann Buy vertretbar ist

  • Commodity-Funktion mit niedrigem Integrationsgrad: HR, Reisekosten, generisches DMS, wenn keine sensiblen Betriebsdaten involviert sind.
  • Streng entkoppelte Teilsysteme: Standardisierte Schnittstellen, bei denen die Hoheit über Daten, Betrieb und Lebenszyklus außerhalb dieses Teilsystems nicht beeinträchtigt wird.
  • Zeitkritischer Brückenschlag: Temporäre Lösung für klar begrenzten Zeitraum mit Exit-Strategie, Data-Export-Garantien und nachweislich geringem Vendor-Lock-in.

Technische Entscheidungsgrundlage statt Folienabstimmung

Eine Build-vs-Buy-Entscheidung gehört in ein formales, technikgetriebenes Verfahren:

  • Domänenziele und Invarianten: Welche Eigenschaften müssen unverändert gehalten werden (z. B. Latenz X ms, vollständige On-Prem-Verarbeitung, keine externen Abhängigkeiten in der CI/CD-Kette, revisionssichere Datenhaltung)?
  • Nichtfunktionale Anforderungen priorisieren: Verfügbarkeit, MTTR, Skalierbarkeit, Auditierbarkeit, Datenlokalität, Sicherheitsmodell (Identitätsquellen, Rollenmodell).
  • Boundary Mapping: Welche Systemgrenzen legen wir so fest, dass Integrationen innen domänensprachlich bleiben und außen über Anti-Corruption-Adapter sprechen?
  • Architekturevaluierung: Für jeden Kandidaten Off-the-Shelf gegen Build-Referenzarchitektur testen. Keine Featurelisten, sondern Tests gegen Invarianten, Betriebsszenarien und Störfälle.
  • Lebenszyklus- und Migrationsstrategie: Nachweis, wie Upgrades/Migrationen ohne Betriebsunterbrechung durchgeführt werden. Konkrete Mechanismen: Blue/Green, Shadow Traffic, Event-Replay, Datenversionierung.

Architektur-Blueprints für die souveräne Variante

1) Domänenzentrierte Kernplattform

  • Kern als modularer Monolith oder kleinteilige Services nur dort, wo reale Skalierung/Isolierung gefordert ist. Übermäßige Microservices vermeiden, wenn sie Latenz/Komplexität treiben.

  • Einheitliches Domänenmodell mit klaren Bounded Contexts. Sprachliche Konsistenz in APIs und Events.

2) Datenebene

  • Transaktionaler Kern mit Event-Sourcing oder Change-Data-Capture, je nach Rückverfolgungsanforderungen.

  • Getrennte Lese-/Schreibhierarchien (CQRS), Materialized Views für Echtzeit-Analysen.

  • On-Prem Objektspeicher für Rohdaten, Datenversionierung für ML/Analytics-Artefakte.

3) Integrationsschicht

  • Anti-Corruption-Layer zu Legacy-Systemen; keine “direkt-auf-DB”-Kopplungen.

  • Asynchrone Integration über Messaging für entkoppelte Skalierung und Resilienz; Idempotenz und Replay-Fähigkeit als Pflicht.