Build vs Buy: Wann individuelle Entwicklung die einzige Option ist

Problem zuerst: In regulierten Branchen entscheidet nicht die Feature-Liste, sondern die Fähigkeit, Betrieb, Sicherheit und Nachvollziehbarkeit unter eigenen Bedingungen zu garantieren. Genau hier scheitert Standardsoftware systematisch – nicht, weil sie „schlecht“ ist, sondern weil ihr Betriebs- und Änderungsmodell nicht zu den Zwängen in Defense, Bahn, Fertigung, Luftfahrt oder kritischer Infrastruktur passt. Wer Datenflüsse nicht kontrollieren kann, wer Änderungen nicht auditierbar über den gesamten Lebenszyklus steuern kann, wer Latenzbudgets und Integrationsgrenzen nicht selbst definiert, wird früher oder später von Governance- und Zertifizierungsanforderungen eingeholt.

In diesem Beitrag skizziere ich einen technischen Entscheidungsrahmen, wann „Build“ (gezielte Eigenentwicklung) nicht nur sinnvoll, sondern notwendig ist. Ich beschreibe Architekturbausteine, die sich in sicherheitskritischen und industriellen Projekten bewährt haben, und zeige, wie man das Risiko einer Eigenentwicklung kontrolliert – fachlich, technisch, organisatorisch.

Wo Off‑the‑Shelf systematisch kollidiert

Die meisten Standardprodukte adressieren ein Durchschnittsumfeld: Internetanbindung ist gegeben, Updates kommen aus der Cloud, Telemetrie verlässt das Netzwerk, der Anbieter entscheidet über Roadmaps. In Branchen mit strengen Auflagen kollidiert das an vier Stellen.

1) Betriebsmodell und Datenpfade

  • Air‑gapped, segmentierte Netze, kein ausgehender Traffic: Viele Produkte benötigen telefonierenden Lizenz- oder Telemetriepfade. Das ist in isolierten Netzen ein Ausschlusskriterium.

  • Datenresidenz und -hoheit: „Bring your own key“ oder Regionseinstellungen lösen nicht das Kernproblem, wenn der Anbieter Betriebszugriff behält oder Systemkomponenten nur als SaaS existieren.

  • Update-Kontrolle: Erzwingt das Produkt automatische Updates, fehlt die Möglichkeit, Änderungen qualifiziert und zeitversetzt freizugeben.

2) Änderungsdruck und Zertifizierbarkeit

  • Reproduzierbarkeit: In auditierbaren Umgebungen müssen Versionen reproduzierbar baubar sein. Proprietäre, intransparente Release-Zyklen behindern das.

  • Traceability: Ohne Ende‑zu‑Ende‑Verfolgbarkeit von Anforderungen über Code bis Test und Betrieb wird jede Rezertifizierung zur Lotterie.

3) Nichtfunktionale Anforderungen

  • Harte Latenzbudgets: Wenn Aktoren binnen Millisekunden reagieren müssen, ist ein Roundtrip in irgendeine Cloud oder ein generischer Messagebus ohne deterministische Backpressure-Kontrolle schlicht falsch.

  • Verfügbarkeit unter Zwang: Hohe MTBF/MTTR‑Ziele, geplante Wartungsfenster, Hardware-Redundanz – das muss das Produktbetriebskonzept nativ können.

4) Observability und Governance bei KI/LLM

  • Standardtools liefern selten die für regulierte Umfelder nötige Nachvollziehbarkeit von ML/LLM‑Entscheidungen: Welche Datenbasis, welches Prompt/Policy‑Set, welche Modellversion, welche Abweichung zur Goldreferenz?

  • Ohne Richtlinienkontrolle („Policy as Code“) und Auditability über alle Agenten- und Modellinteraktionen wird KI im Betrieb zur Blackbox.

Entscheidungsrahmen: Sechs Achsen, die „Build“ erzwingen

Statt Feature-Listen abzugleichen, betrachten wir sechs strukturelle Achsen. Sobald Sie auf mehreren Achsen harte Anforderungen haben, wird „Buy“ zum Integrations- und Governance-Risiko.

1) Datenhoheit und Betriebsmodell

  • Müssen kritische Daten das Netzwerk nie verlassen?

  • Ist Air‑Gap/geschlossene Zone Pflicht?

  • Dürfen Updates nur nach formaler Freigabe installiert werden?

  • Brauchen Sie Offline‑Fähigkeit inkl. Lizenzierung?

Wenn Sie hier mehrmals „ja“ sagen, brauchen Sie eine Architektur, die on‑premise, offline und signaturbasiert betreibbar ist – von Artefakt-Distribution bis Konfigurationsmanagement.

2) Sicherheits- und Lieferkettenmodell

  • Können Sie für jede Komponente eine Software‑Stückliste (SBOM) und signierte Artefakte verlangen und verifizieren?

  • Kontrollieren Sie Abhängigkeiten (private Registries, Mirrors) und Build‑Pipelines (reproduzierbare Builds, Vier-Augen‑Freigabe)?

  • Sind Betriebs-Accounts, Secrets und Schlüssel vollständig in Ihrer Hand?

Fehlen diese Kontrollen, importieren Sie Supply‑Chain‑Risiken und verlieren im Incidentfall Handlungssouveränität.

3) Determinismus und Nachvollziehbarkeit (insb. bei ML/LLM)

  • Können Sie eine Entscheidung reproduzieren: Datenversion, Feature‑Engineering, Modellversion, Prompt/Policy, Laufzeitkontext?

  • Haben Sie Datasets, Evaluationssuiten und Golden‑Runs versioniert?

  • Gibt es einen formalen Degradationsmodus bei Unsicherheit?

Wenn nicht, ist ein Audit kaum zu bestehen. Eigenentwicklung erlaubt, Reproduzierbarkeit und Nachvollziehbarkeit als Querschnittsanforderung zu verankern.

4) Integrationstiefe und Latenzgarantien

  • Müssen Feldgeräte/PLC/Avionik mit harten Deadlines bedient werden?

  • Benötigen Sie deterministische Scheduling‑Strategien (CPU/GPU/IO)?

  • Müssen Sie Altanlagen ohne Downtime integrieren (Brownfield)?

Standardprodukte bieten selten deterministische End‑to‑End‑Pfade. Eigenentwicklung ermöglicht idempotente, backpressure‑feste Pipelines und gezieltes Ressourcen‑Scheduling.

5) Vendor‑Lock‑in und Lebenszyklus

  • Was passiert bei EOL oder Strategiewechsel des Anbieters?

  • Können Sie Daten/Modelle/Policies verlustfrei exportieren?

  • Haben Sie alternative Bezugsquellen oder ist alles proprietär?

Fehlt ein sauberer Exit‑Pfad, ist der Preis eines „günstigen“ Kaufs die langfristige Abhängigkeit. Build erlaubt, Schnittstellen, Datenformate und Migrationspfade von Anfang an zu kontrollieren.

6) Zertifizierbarkeit und Qualitätssicherung

  • Können Sie Anforderungen, Architekturentscheidungen, Tests, Metriken und Betriebsereignisse lückenlos verketten?

  • Sind Teststrategien formalisierbar (z. B. szenariobasiert, metamorph, regressionsstabil)?

  • Lässt sich jede Änderung als Change‑Set mit Risikoanalyse bewerten?

Eigenentwicklung gibt die Chance, Traceability und V&V als Systemfunktion zu bauen, statt sie nachträglich zu dokumentieren.

Architekturbausteine für „Build“

Eigenentwicklung bedeutet nicht „alles selbst bauen“. Es heißt: Sie definieren die architektonisch kritischen Komponenten, kontrollieren Schnittstellen und betreiben unter Ihren Bedingungen. Folgende Bausteine haben sich bewährt.

1) Domänenmodell und Schnittstellen zuerst

  • Gemeinsames Informationsmodell: Entitäten, Zustände, Lebenszyklen, Identitäten, Zeitbezug. Ohne sauberes Modell werden Integrationen brüchig.

  • Stabile, versionierte Schnittstellen: Explizite Datenverträge, schema‑ und semantikversioniert. Abwärtskompatibilität ist eine Betriebsfähigkeit, kein Zufall.

  • Befehls- und Ereignisgrenzen: Was ist synchroner Befehl (mit Latenzbudget), was ist asynchrones Ereignis (mit idempotenter Verarbeitung)?