Build or Buy: Wie IT-Entscheidungen die Systemlandschaft prägen
Eine interaktive Simulation zeigt, wie Build-vs-Buy-Entscheidungen Budget, Personal und die langfristige Architektur beeinflussen – und warum es keine einfachen Antworten gibt.
Build or Buy: Wie IT-Entscheidungen die Systemlandschaft prägen
In meinem täglichen Doing als Platform Engineer und Architekt bin ich ständig mit der Frage konfrontiert: Build or Buy? Sollen wir eine CI/CD-Pipeline selbst bauen, GitHub Actions kaufen oder auf Open Source wie GitLab CI setzen? Ein Data Warehouse selbst entwickeln oder Snowflake lizenzieren?
Diese Entscheidungen klingen technisch, sind aber fundamental strategisch. Sie bestimmen nicht nur kurzfristige Kosten, sondern formen die gesamte Systemlandschaft für Jahre.
Die drei Archetypen
In der Praxis gibt es nicht nur “Build” oder “Buy”, sondern drei grundlegende Strategien:
1. Build (Eigenentwicklung)
- Kosten: Keine Lizenzgebühren, aber hohe Entwicklungskosten
- Personal: Intensiv – Entwicklung, Wartung, Weiterentwicklung
- Flexibilität: Maximal – volle Kontrolle über Features
- Risiko: Technische Schulden, Abhängigkeit von internen Experten
2. Buy Enterprise
- Kosten: Hohe laufende Lizenzkosten
- Personal: Minimal – Vendor übernimmt Support und Updates
- Flexibilität: Begrenzt – Features werden diktiert
- Risiko: Vendor Lock-in, Preiserhöhungen
3. Open Source
- Kosten: Niedrig – eventuell Hosting-Kosten
- Personal: Moderat – Setup, Configuration, Upgrades
- Flexibilität: Hoch – Community-Support, eigene Anpassungen möglich
- Risiko: Support-Qualität, Breaking Changes, Forks
Die versteckte Komplexität
Das eigentliche Problem: Jede Entscheidung isoliert betrachtet macht Sinn. Aber die Summe aller Entscheidungen erzeugt die Systemlandschaft – und die ist oft heterogen, komplex und teuer.
Drei selbstgebaute Systeme binden dauerhaft Personal. Fünf Enterprise-Lizenzen sprengen das Budget. Sechs Open-Source-Tools ohne einheitliches Monitoring sind ein Wartungs-Albtraum.
Interaktives Management-Game
Die folgende Simulation ist ein Multi-Level-Spiel, das die typische Entwicklung einer Enterprise-IT-Landschaft nachbildet. Du durchläufst 4 Departments (Sales, Logistics, Marketing, Accounting) und musst für jede Anforderung die richtige Build-or-Buy-Entscheidung treffen.
Spielmechanik:
- 🎯 4 Levels mit verschiedenen Departments und Anforderungen
- 💰 Limitiertes Budget und Personal pro Level
- 🏢 10+ Vendors (Salesforce, SAP, Microsoft, Google, Adobe, etc.)
- 📊 Scoring-System mit Vendor-Konsolidierungs-Bonus
- 🗺️ Finale Systemlandschaft zeigt deine Architektur-Entscheidungen
Ziel: Maximiere deinen Score durch kluge Balance zwischen Build, Buy und Open Source – und halte die Vendor-Anzahl niedrig!
Level 1: Sales
Das Sales-Team braucht grundlegende Tools für Kundenmanagement
Was das Game zeigt
1. Vendor-Konsolidierung ist wertvoll
Das Scoring-System bestraft viele verschiedene Vendors. In der Realität bedeutet das:
- Verhandlungsmacht: Weniger Vendors → bessere Konditionen
- Integration: Systeme vom gleichen Vendor spielen besser zusammen
- Support: Ein zentraler Ansprechpartner statt zehn verschiedene
- Aber: Vendor Lock-in ist real – zu viel Abhängigkeit von einem Anbieter ist gefährlich
2. Jedes Department hat andere Prioritäten
- Sales (Level 1): Braucht schnelle Tools, CRM ist kritisch
- Logistics (Level 2): Komplexe Prozesse, SAP/Oracle oft Standard
- Marketing (Level 3): Viele Vendor-Optionen, HubSpot vs. Salesforce vs. Adobe
- Accounting (Level 4): ERP-Entscheidung prägt die gesamte IT-Landschaft
3. Maintenance wird unterschätzt
Nach 4 Levels zeigt die finale Landschaft: Maintenance summiert sich. Ein selbstgebautes System kostet 10-25 Tage/Jahr. Bei 10+ Custom-Builds bindet das mehrere FTEs dauerhaft.
4. Budget-Druck erzwingt Trade-offs
Nicht jedes Level hat genug Budget für Enterprise-Tools. Strategische Entscheidungen:
- Wo kaufen wir Premium? (z.B. Salesforce CRM)
- Wo reicht Open Source? (z.B. Metabase statt Tableau)
- Was bauen wir selbst? (z.B. Custom Integrations)
Die Realität: Strategische Trade-Offs
In der Praxis gibt es drei häufige Strategien:
A) Buy Core, Build Differentiators
- Kern-Infrastruktur kaufen (Monitoring, Auth, Cloud)
- Business-Logik selbst bauen (Domain-spezifische Tools)
- Vorteil: Fokus auf Wettbewerbsvorteile
- Risiko: Hohe Lizenzkosten für Basis-Tools
B) Open Source Base, Managed Services on Top
- Open-Source-Tools als Basis (Kubernetes, PostgreSQL, Airflow)
- Managed Services für Ops (AWS RDS, GCP GKE)
- Vorteil: Flexibilität + weniger Ops-Last
- Risiko: Cloud-Vendor Lock-in
C) Hybrid mit klaren Prinzipien
- Regelwerk definieren: z.B. “Security = Buy Enterprise, Dev Tools = Open Source”
- Ausnahmen dokumentieren
- Vorteil: Konsistente Architektur-Entscheidungen
- Risiko: Prinzipien werden im Alltag ignoriert
Fazit: Context over Dogma
Es gibt keine universelle Regel. “Immer Buy” ist genauso naiv wie “Alles Open Source”. Die richtige Strategie hängt ab von:
- Team-Größe: Kleines Team → mehr Buy/Managed
- Budget-Situation: Limited Budget → mehr Open Source + Build
- Time-to-Market: Schnelle Launches → mehr Buy
- Differenzierung: Unique Features → Build
- Compliance: Regulierte Industries → oft Buy Enterprise mit SLAs
Die Simulation oben zeigt: Jede Entscheidung ist ein Trade-off. Und die Summe dieser Trade-offs formt die Systemlandschaft, mit der dein Team die nächsten Jahre leben muss.
Die Frage ist nicht “Build or Buy?”, sondern: “Welche Komplexität wollen wir managen – und welche auslagern?”
Das Scoring-System verstehen
Das Game vergibt Punkte basierend auf:
- +100 Punkte pro erfüllter Anforderung
- -50 Punkte pro zusätzlichem Vendor (mehr als 1)
- +5 Punkte pro gespartem Personentag
- +1 Punkt pro 100€ gespartem Budget
- -30 Punkte pro Custom Build über 2 hinaus
Optimale Strategien:
- 🏆 Vendor-Cluster: Wähle 2-3 Hauptvendors und konsolidiere (z.B. “Microsoft + Salesforce + Open Source”)
- 💡 Strategic Build: Baue nur, was wirklich Business-differenzierend ist
- 🌐 Open Source als Joker: Günstig, aber nicht überall optimal
Die finale Systemlandschaft-Visualisierung zeigt dir am Ende, welche Architektur du erschaffen hast – und welche Konsequenzen das für die nächsten Jahre hat.