Build-vs-Buy-Entscheidung
Entscheidungsrahmen zur Abwägung, ob eine Lösung intern entwickelt oder extern beschafft werden sollte.
Klassifikation
- KomplexitätMittel
- AuswirkungOrganisatorisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Vendor-Lock-in und eingeschränkte Flexibilität.
- Unterschätzung der Integrations- und Betriebskosten.
- Fehlende strategische Kontrolle bei wichtigen Kernfunktionen.
- Klein anfangen: Proof-of-Concepts für beide Optionen validieren.
- Lifecycle-Kosten über mehrere Jahre betrachten.
- Vertragliche Exit-Klauseln und SLAs klar regeln.
I/O & Ressourcen
- Produktvision und Roadmap
- Technische Anforderungen und Architekturübersicht
- Kosten- und Ressourcenabschätzung
- Dokumentierte Entscheidungsgrundlage mit Optionenvergleich
- Empfohlener Umsetzungsplan und Zeitplan
- Identifizierte Risiken und Migrationspfade
Beschreibung
Die Build-vs-Buy-Entscheidung ist ein strukturelles Entscheidungsmodell zur Bewertung, ob Software oder Komponenten intern entwickelt oder extern beschafft werden sollen. Sie berücksichtigt Kosten, Time-to-Market, strategischen Wettbewerbsvorteil und Betriebskosten. Ziel ist eine transparente, kontextuelle Wahl basierend auf Risiken und Nutzen. Sie erfordert cross-funktionale Beteiligung von Produkt, Technik und Einkauf.
✔Vorteile
- Reduzierte Time-to-Market bei Nutzung bestehender Lösungen.
- Kontrolle und Differenzierung bei Eigenentwicklung.
- Transparente Risiko- und Kostenbewertung ermöglicht fundierte Entscheidungen.
✖Limitationen
- Nicht alle Anforderungen lassen sich durch Standardprodukte abdecken.
- Interne Entwicklung bindet Ressourcen und verlängert Lieferzeiten.
- Externe Anbieter können langfristige Abhängigkeiten erzeugen.
Trade-offs
Metriken
- Time-to-Market
Zeit bis zur Verfügbarkeit der Funktionalität für Nutzer.
- Total Cost of Ownership (TCO)
Kumulierte Kosten über den betrachteten Lebenszyklus.
- Risiko-Score
Kombinierte Bewertung technischer, rechtlicher und operativer Risiken.
Beispiele & Implementierungen
Nutzung eines Zahlungsdienstleisters statt eigener Zahlungsplattform
Startup reduziert Time-to-Market durch Integration eines SaaS-Zahlungsanbieters statt interner Entwicklung.
Eigenentwicklung einer Kern-Suchfunktion
Unternehmen entscheidet sich für Eigenentwicklung, um differenzierende Suchqualität und Kontrolle zu sichern.
Einsatz eines Managed-Hosting-Anbieters für Infrastruktur
Organisation verlagert Betrieb an Managed Service, um Betriebsaufwand zu reduzieren und Fokus auf Produktfunktionen zu legen.
Implementierungsschritte
Anforderungen konsolidieren und priorisieren
Marktrecherche und Anbieterbewertung durchführen
Kosten-, Risiko- und TCO-Analyse erstellen
Cross-funktionales Review und finale Entscheidung dokumentieren
⚠️ Technische Schulden & Engpässe
Tech Debt
- Wachsende Wartungslast durch stark angepasste Vendor-Komponenten.
- Altlasten durch fragmentierte Eigenentwicklungen ohne Standards.
- Fehlende Dokumentation nach Schnellentscheidungen zugunsten schneller Lieferung.
Bekannte Engpässe
Beispiele für Missbrauch
- Ein Unternehmen baut eine nicht-differenzierende Infrastrukturkomponente statt günstige SaaS-Lösung zu nutzen.
- Produktteam entscheidet ohne Einbindung von Betrieb und Security — Folge: hoher Nacharbeitsaufwand.
- Einkauf schließt langfristigen Vertrag ohne technische Validierung ab.
Typische Fallen
- Unterschätzung laufender Integrations- und Betriebskosten.
- Ignorieren zukünftiger Skalierungsanforderungen beim Kauf.
- Fehlende Exit-Strategie bei Vendor-Entscheidungen.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Budgetrahmen und Finanzierungszyklen
- • Regulatorische Anforderungen und Datenhoheit
- • Organisatorische Entscheidungs- und Beschaffungsprozesse