6) Governance formalisieren

  • Architekturentscheidungen (ADR), Risk Register, Change Management, Modell-Governance bei KI. Ohne Governance skaliert Build nicht.

Warum dieser Weg Projekte rettet: Technical Ownership

Technical Ownership bedeutet, dass Architektur, Qualität und Betrieb nicht „verteilt“ verantwortet werden, sondern eine klare, technische Eigentümerschaft existiert. Das ist keine Organigrammfrage, sondern ein Engineering-Prinzip:

  • Eine Hand am Gaspedal: Metrikgestützt priorisieren, nicht „Feature by Escalation“.

  • Eine Quelle der Wahrheit: Anforderungen, Modelle, Tests und Artefakte konsistent versioniert.

  • Eine Abnahmekultur: Messen gegen SLAs/NFAs, nicht gegen Marketingfolien.

Ohne Ownership degeneriert jedes komplexe System zu einer Sammlung lokaler Optimierungen – und genau das ist die Ursache vieler Migrations- und AI-Projektmiseren.

Fazit

Build vs Buy ist keine Glaubensfrage, sondern eine Risiko- und Souveränitätsentscheidung. In regulierten und industriellen Umgebungen sind die nicht-funktionalen Anforderungen der primäre Treiber. Wenn Datenhoheit, Offline-Fähigkeit, deterministische Performance und Auditierbarkeit nicht verhandelbar sind, ist Build nicht Luxus, sondern Berufsstandard. Die gute Nachricht: Mit den richtigen Architekturmustern, Governance-Praktiken und einer konsequenten Ownership-Kultur ist Build kalkulierbar, beherrschbar und langfristig oft günstiger – weil die Änderungsökonomie zu Ihren Gunsten kippt.

FAQ

Frage: Wie beginne ich, ohne monatelang ein Lastenheft zu schreiben?
Antwort: Definieren Sie zuerst die Non-Negotiables und die wichtigsten SLAs/NFAs. Starten Sie dann eine zeitlich begrenzte Spike-Phase (6–8 Wochen) mit realistischen Daten und Lastprofilen. Ziel: Architektur- und Betriebsrisiken messbar reduzieren. Ergebnisse fließen in ADRs und ein minimal tragfähiges Architektur-Backbone.

Frage: Wie vermeide ich Vendor-Lock-in, wenn ich doch einkaufen muss?
Antwort: Trennen Sie Daten und Kontrolle von der Funktionalität. Daten bleiben bei Ihnen, Schnittstellen sind offen und versioniert, Infrastruktur-Kontrollpunkte (Auth, Observability, Artefaktlieferung) liegen in Ihrer Domäne. Verwenden Sie Ports/Adapters, damit Wechselkosten nicht explodieren.

Frage: Wie schätze ich die Kosten für Build realistisch ein?
Antwort: Arbeiten Sie mit einem Run-Cost Envelope (geplante, wiederkehrende Betriebskosten) und einer Change-Tax-Quote (Kosten pro Änderungseinheit). Prototypische Implementierungen der risikoreichsten Pfade (nicht der „Hello World“-Teile) liefern die besten Daten. Planen Sie von vornherein für Testautomatisierung, Observability und Security – diese Kosten sind nicht optional.

Frage: Wie sichere ich KI/LLM-Systeme on-prem ab?
Antwort: Stellen Sie eine Governance-Schicht vor das Modell: vollständige Protokollierung, Policy-Enforcement, isolierte Inferenzdienste, versionierte Prompt-/Tool-Kataloge, Datenklassifizierung vor jeder Interaktion. Modelle und Vektorspeicher bleiben on-prem, Artefakte sind signiert, Re-Trainings sind reproduzierbar.

Frage: Was tun, wenn der Fachbereich „schnell Ergebnisse“ sehen will?
Antwort: Zeigen Sie Ergebnisse dort, wo es das Risiko reduziert: Schattenbetrieb mit realen Daten, aussagekräftige SLAs und NFAs, sichtbare Abweichungen. Ein schneller „Demo-Erfolg“ ohne NFA-Abdeckung produziert nur spätere Projektkosten. Schnelligkeit ist akzeptabel, wenn sie messbar, wiederholbar und auditierbar ist.