• Invarianten definieren: Datenlokalität, Latenz, Availability-Ziele, Auditierbarkeit, Upgrade-Kontrolle.
  • Systemgrenzen festlegen: Was ist Kern (Build), was kann als klar abgrenzbare Capability eingekauft werden (Buy)?
  • Integrationsrisiken bewerten: Protokolle, Latenz, Offline-Fähigkeit, Sicherheitsdomänen.
  • Lebenszyklus planen: Update-Fenster, Migrationsstrategie, Reproduzierbarkeit, Teamfähigkeiten.
  • Governance sichern: Security-Modell, Observability, Change-Management, AI-Governance (falls relevant).
  • Exit-Strategien definieren: Für jeden externen Baustein einen verifizierten Migrationspfad hinterlegen.

Häufige Fehler und wie man sie vermeidet

  • Feature-Fokus statt Invarianz-Fokus: Die hübscheste Roadmap hilft nichts, wenn Daten nicht dort bleiben dürfen, wo sie müssen. Invarianten zuerst bewerten, Features zuletzt.
  • Architektur-Over-Engineering: Microservices ohne Last-/Isolationsbedarf erhöhen nur den operativen Schmerz. Modularer Monolith ist oft die ehrlichere Wahl.
  • Telemetrie- und Lizenzblindheit: Lizenzserver und “anonyme” Telemetrie sind oft die heimlichen Internetabhängigkeiten. Frühzeitig eliminieren.
  • Fehlende Rollback-Pfade: Jedes Deployment braucht klaren Rückweg. Ohne das sind Wartungsfenster Roulette.
  • Kein Technical Owner: Wenn niemand Verantwortung für Architekturentscheidungen trägt, frisst Integrationskomplexität jeden Plan.

Fazit

Build ist keine Ideologie. In regulierten und sicherheitskritischen Domänen ist Build häufig die pragmatische, kosteneffiziente Antwort auf Anforderungen, die Standardsoftware architektonisch nicht erfüllen kann: Datenhoheit, Determinismus, langlaufende Lebenszyklen, spezialisierte Integrationen und prüfbare Governance – besonders bei lernenden Systemen. Die richtige Frage ist nicht “Wie schnell kommen wir zum ersten Go-Live?”, sondern “Welche Systeminvarianten müssen über zehn Jahre hinweg unter unserer Kontrolle bleiben – und welche Architektur garantiert uns das?”.

FAQ

Frage: Wie rechtfertige ich Build gegenüber dem CFO ohne in endlose Kostendebatten abzurutschen?
Antwort: Stellen Sie nicht CAPEX gegen OPEX, sondern Roadmap-Risiko und Lock-in-Kosten über die Lebensdauer. Legen Sie die Invarianten offen (z. B. On-Prem only, definierte Latenzen, auditierbare Datenflüsse) und zeigen Sie auf, welche Aufwände im Buy-Fall zur Kompensation entstehen (Compliance-Mehrarbeit, Migrationskosten bei Roadmap-Drift, Betriebsrisiken). Ein belastbarer TCO-Vergleich enthält auch die Kosten für Exit-Strategien, die bei Build kontrollierbar und bei Buy oft unplanbar sind.

Frage: Wir haben keine große Inhouse-Mannschaft. Ist Build für uns überhaupt machbar?
Antwort: Ja, wenn Sie Technical Ownership klar definieren und fokussieren. Starten Sie mit einem kleinen Kernteam für Architektur, DevOps und Qualität und ergänzen Sie gezielt externe Expertise. Halten Sie den Kern eigen: Domänenmodell, Security, Deploy-/Release-Prozess. Den Rest können Sie modular zukaufen, solange die Grenzen technisch sauber bleiben.

Frage: Wie minimiere ich das Projektrisiko beim Build-Ansatz?
Antwort: Durch schrittweises Vorgehen mit messbaren Invarianten: Anti-Corruption-Layer, Shadow Traffic, Strangler-Fig, Blue/Green. Setzen Sie ADRs ein, um Entscheidungen nachvollziehbar zu machen. Investieren Sie früh in Observability, CI/CD, Testautomatisierung und Reproduzierbarkeit. Ohne das ist jedes Build-Vorhaben eine Wette.

Frage: Was ist die größte technische Schulde, die bei Buy in regulierten Umgebungen entsteht?
Antwort: Verdeckte Abhängigkeiten in Betrieb und Telemetrie. Lizenzserver, Update-Mechanismen, Cloud-gebundene Konfigurationen oder “anonyme” Nutzungsdaten sind in isolierten Netzen brandgefährlich. Sie untergraben Souveränität und provozieren spätere Notfall-Umbauten.

Frage: Wie gehe ich mit KI/LLM-Themen um, wenn ich keine Cloud-Anbindung nutzen darf?
Antwort: Planen Sie von Beginn an On-Premise-Governance: Versionierte Prompts/Policies, Telemetrie und Evaluation lokal, Inferenz-Workloads auf interner Infrastruktur, klare Trennung zwischen Experimenten und Produktion, Policy-Enforcement vor Aktionsausführung. Eine darauf ausgelegte Observability- und Governance-Schicht ist Pflicht, nicht Kür. So bleiben Sie handlungsfähig, auch ohne externe Abhängigkeiten.

Wenn Sie diese Prinzipien befolgen, ist Build kein Selbstzweck, sondern der kontrollierbare Weg zu Systemen, die Ihre betrieblichen und regulatorischen Realitäten respektieren – heute und in zehn Jahren.