• Bahn/Fleet Intelligence:
  • Kernanforderungen: Datenhoheit über Flottentelemetrie, strikte Mandantentrennung pro Betreiber, Offline‑Synchronisation.
  • Architektur: Data Plane in isolierten Mandanten, Control Plane zentral on‑prem; klare Trennlinien, eventgetriebene Replikation, Audit‑Trails bei jeder Transformationsstufe.
  • Defense‑nahe Systeme:
  • Kernanforderungen: Air‑Gap, deterministische Ausfallszenarien, überprüfbare Softwarestände.
  • Architektur: Minimaler OS‑Footprint, read‑only Root‑FS, Hardware‑In‑The‑Loop‑Tests, signierte Artefaktlieferkette, ausdrucksstarke Fehlerzustände für Operatoren.

Warum der „Buy“-Pfad oft teurer ist, als er aussieht

Off‑the‑Shelf sieht im Angebot oft günstiger aus. Die versteckten Kosten liegen in den Lebenszyklus- und Integrationsdetails:

  • Lizenz- und Nutzungsgebühren:
  • Vermehrungsfaktor pro Linie, pro Anlage, pro Benutzer; unklare Cluster‑Lizenzierung.
  • Spätere Preiserhöhungen, Zusatzmodule nötig für „eigentlich selbstverständliche“ Funktionen.
  • Betrieb und Egress:
  • Netzwerk- und Egress‑Gebühren bei Cloud‑Modellen oder Telemetrie.
  • Kosten für zusätzliche Härtungsmaßnahmen, wenn der Hersteller kein On‑Prem‑Hardening vorsieht.
  • Vendor‑Lock und Roadmap‑Risiko:
  • Änderungen in API/Vertragsbedingungen; Funktionen wandern in höhere Tiers.
  • Ende des Produktsupports, Migrationszwang zum Nachfolger.
  • Audit- und Compliance‑Aufschläge:
  • Zusatzaufwand, um black‑box‑Verhalten einem Auditor zu erklären.
  • Individuelle Sonderfreigaben, weil Standardprozesse des Anbieters nicht zu Ihrer Governance passen.

Demgegenüber sind Build‑Kosten sichtbarer, aber steuerbarer:

  • Anfangsinvest in Architektur, Entwicklungs- und QS‑Setup.

  • Kontinuierliche Kosten für Team, Backlog, Betrieb.

  • Planbare Updates, keine Fremdterminzwänge, keine erzwungenen Produktwechsel.

Wenn der Kern Ihres Systems differenzierend ist oder die Compliance‑Last hoch, kippt die TCO‑Rechnung häufig zugunsten von Build. Das gilt insbesondere dann, wenn Sie Komponenten wiederverwenden können (Plattformansatz über mehrere Linien/Standorte hinweg) und technische Ownership ernst nehmen.

Technische Ownership als Risikosenke

„Ownership“ ist mehr als ein schickes Wort in Präsentationen. Es ist die Menge an Entscheidungen, die Sie im Ernstfall selbst treffen können, ohne auf einen Dritten zu warten.

Praktiken, die Ownership greifbar machen:

  • Architekturhoheit:

  • Eindeutige Verantwortlichkeiten, dokumentierte Architekturentscheidungen (ADRs).

  • Eindeutige Definition von Systemgrenzen, Vertrauensankern, Non‑Negotiables.

  • Test- und Freigabekultur:
  • Contract‑Tests gegen jede externe Schnittstelle.
  • Property‑based Tests für kritische Algorithmen.
  • Hardware‑/Software‑In‑The‑Loop für Echtzeitpfade.
  • Canary/Shadow‑Deployments auch on‑prem, Feature‑Flags, schnelle Rollbacks.
  • Reproduzierbarkeit:
  • Deterministische Builds, SBOM, signierte Artefakte.
  • Isolierte Build‑Pipelines, die offline lauffähig sind.
  • Observability und Governance:
  • Vollständige Telemetrie unter eigener Kontrolle.
  • KI-/LLM‑Sichtbarkeit: Eingaben, Kontexte, Entscheidungen, Policies – ohne externe Abhängigkeit.
  • Team- und Wissensaufbau:
  • Dokumentierte Betriebs- und Debug‑Playbooks.
  • On‑Call mit Entscheidungskompetenz und Zugriff auf Ursachenanalysen.

Anti‑Pattern, die Projekte kippen lassen

  • „Wir kaufen X und integrieren später“ – die Integrationslast trifft Sie trotzdem, nur später und teurer.
  • „Cloud‑first“ ohne Betrachtung des Zielbetriebs – Air‑Gap‑Portierung ist kein Schalter.
  • „Einmaliges PoC mit Public‑API, dann hochskalieren“ – Produktivbetrieb in regulierten Umfeldern scheitert am Audit.
  • „Wir migrieren Big‑Bang“ – Legacy‑Ablösung ohne Strangler‑Pattern endet in Betriebspausen.
  • „Wir sehen Telemetrie als Nebensache“ – Ohne Observability werden Fehler unsichtbar, Audits schmerzhaft.

Wie man den Build‑Pfad realistisch plant

  • Scope sauber schneiden:
  • Was ist Kern (Build)? Was ist Commodity (Buy)? Dokumentieren.
  • Schnittstellen anhand von Verträgen definieren, nicht anhand aktueller Implementierungen.
  • Architektur runway:
  • Minimale lauffähige Plattform: CI/CD, Artefakt‑Repo, Observability, Secrets, Konfigurationsmanagement.
  • Sicherheits- und Zonenmodell frühzeitig umsetzen.
  • Parallelität und Risiko:
  • Strangler‑Fig‑Pattern nutzen, Shadow‑Traffic, Doppel‑Buchungen (Double‑Write) während der Transition.
  • Rollback‑Pfade durchdeklinieren, Disaster‑Recovery testen.
  • QS von Anfang an:
  • Testpyramide mit Hardware‑ und Lasttests.
  • Freigabeprozesse formalisieren; Änderungen sind Event plus Audit‑Eintrag.
  • Lieferkette:
  • Abhängigkeiten minimieren, Third‑Party‑Komponenten inventarisieren, SBOM pflegen.
  • Lizenzen klären, Escrow wenn nötig, Update‑Mechanik definieren.

LLM‑Systeme: Besonderheiten im Build‑Kontext

Große Sprachmodelle und Agenten verlocken durch schnelle Prototypen mit Public‑APIs. In regulierten Umfeldern gelten zusätzliche Spielregeln:

  • Modellzugang:
  • On‑Prem oder dedizierte europäische Deployment‑Modelle; keine unkontrollierten Prompt‑/Kontext‑Abflüsse.
  • Eigenes Embedding/Vector‑Store on‑prem, Retrieval mit strict data scoping.
  • Policies und Safety:
  • Domain‑Policies als ausführbarer Code (z. B. Guardrails), nicht nur als Dokument.
  • Tests für Prompt‑Leckagen, Halluzinations‑Detektoren im Schattenmodus.
  • Observability:
  • Vollständige Sicht auf Token‑Ströme, Prompts, System‑ und Tool‑Aufrufe.
  • Governance, die Antworten erklärbar und reproduzierbar macht.
  • Update und Reproduzierbarkeit:
  • Versionierung von Modellen, Tokenizern, System‑Prompts, Tools.
  • Offline‑Freigaben mit signierten Artefakten.

Eine Governance‑ und Observability‑Plattform für LLM‑Workloads on‑prem ist hier kein „nice to have“, sondern die Voraussetzung, um Audits zu bestehen und Vorfälle aufzuklären. Der konkrete Produktname spielt weniger eine Rolle als die Eigenschaft, ohne US‑Cloud‑Abhängigkeit lauffähig zu sein.

Kostenkategorien für eine 3‑Jahres‑Betrachtung

Ohne in absolute Zahlen zu gehen, sollten Sie TCO so strukturieren:

  • Build:
  • Einmalig: Architektur, Plattform‑Setup, Härtung, QS‑Rahmen, Migrationsadapter.
  • Laufend: Produktentwicklung, Betrieb (SRE), Sicherheitsupdates, Audits, Hardware‑Erneuerung.
  • Optional: Schulungen, Dokumentation, Wissenssicherung.
  • Buy:
  • Einmalig: Integration, Anpassung, Datenmigration, Sicherheitsfreigaben, Härtung.
  • Laufend: Lizenzen/Nutzung, Betrieb, Audit‑Aufschläge, Änderungsaufträge beim Anbieter.
  • Versteckt: Preisänderungen, Roadmap‑Änderungen, Daten‑Egress, Produktabkündigung.

Wenn Kernfunktionen mit hoher Änderungsrate oder strengen Nachweispflichten betroffen sind, amortisiert sich Build oft früher als erwartet – insbesondere, wenn Sie eine Plattform über mehrere Produkte/Standorte hebeln.

Migration von Buy zu Build ohne Betriebsunterbrechung