Build vs. Buy vs. Adopt — Technologie-Entscheidungen

Lernziele

Nach dieser Lektion kannst du Technologie-Entscheidungen für Plattform-Komponenten strukturiert treffen: Build (selbst entwickeln), Buy (kommerziell kaufen) oder Adopt (Open Source übernehmen und betreiben). Du kennst die ehrlichen Kosten jeder Option — inklusive der gern übersehenen —, kannst Kriterien wie Differenzierung, Total Cost of Ownership und Exit-Strategie anwenden und eine solche Entscheidung im Interview verteidigen.

Das Problem: jede Capability ist eine Grundsatzentscheidung

Eine Plattform besteht aus einem Dutzend großer Bausteine: Portal, GitOps, CI, Policy-Engine, Observability, Secrets-Management. Für jeden gibt es Open-Source-Projekte, kommerzielle Produkte und die Option, selbst zu bauen — und jede dieser Entscheidungen bindet die Organisation auf Jahre. Trotzdem fallen sie oft erstaunlich beiläufig: Ein Engineer kennt Tool X aus dem letzten Job, also wird es Tool X. Ein Vendor hatte die beste Demo, also wird gekauft. Das Team baut gern selbst, also wird gebaut.

Das Muster dahinter: Die sichtbaren Kosten (Lizenzpreis, initiale Entwicklungszeit) dominieren die Entscheidung, während die unsichtbaren Kosten — Betrieb, Upgrades, Wissensaufbau, Wartung über Jahre — die Rechnung am Ende bestimmen. Ein strukturiertes Vorgehen macht genau diese unsichtbaren Posten explizit, bevor unterschrieben oder losgelegt wird.

Die drei Optionen mit ihren ehrlichen Preisschildern

Adopt (Open Source übernehmen) — Backstage als Portal, ArgoCD für GitOps, Kyverno als Policy-Engine. Sichtbar: keine Lizenzkosten, kein Vendor-Vertrag, große Communities. Unsichtbar: Adopt heißt betreiben. Du trägst Upgrades, Sicherheits-Patches, Skalierung, das Debugging in fremdem Code und die Integration in deine Umgebung — bei einem Projekt wie Backstage ist die Anpassung an die eigene Organisation ein dauerhaftes Entwicklungs-Investment, kein Installationsschritt. Open Source ist kostenlos wie ein geschenkter Welpe: Die Anschaffung ist nicht das Problem. Dazu kommt das Projektrisiko: Governance, Release-Tempo und die Frage, was passiert, wenn der Hauptsponsor das Interesse verliert.

Buy (kommerziell) — gemanagte Portale, Observability-SaaS, Enterprise-Distributionen. Sichtbar: schneller Start, Support mit SLA, Betrieb ausgelagert, oft Enterprise-Anforderungen (SSO, Audit) ab Werk. Unsichtbar: Lock-in und Preisrisiko. Die Kosten skalieren häufig mit Nutzung oder Nutzerzahl und können nach der Einführung steigen, wenn der Wechsel teuer geworden ist; Roadmap-Prioritäten setzt der Vendor, nicht du. Außerdem verschwindet der Integrationsaufwand nicht — auch gekaufte Produkte müssen in Identity, Prozesse und bestehende Tools eingebettet werden.

Build (selbst entwickeln) — die eigene Platform API aus Lektion 8, ein internes CLI, firmenspezifische Automatisierung. Sichtbar: maximale Passgenauigkeit. Unsichtbar: Build ist ein Abo, kein Projekt. Software, die nicht weiterentwickelt wird, verrottet — die initiale Entwicklung ist erfahrungsgemäß der kleinere Teil der Lebenszeitkosten. Dazu der Opportunitäts-Posten: Jede Person, die das Eigenbau-CI pflegt, baut keine Capability, die Entwickler schneller macht. Und das Bus-Faktor-Risiko: Eigenbauten hängen oft an zwei, drei Köpfen.

Entscheidungskriterien, die tragen

Vier Fragen sortieren die meisten Fälle:

1. Ist das Differenzierung oder Commodity? Die wichtigste Frage. Ein CI-System, eine Policy-Engine, ein Metrik-Stack unterscheiden deine Firma nicht vom Wettbewerb — Commodity, also Adopt oder Buy. Selbst bauen lohnt nur, wo deine Anforderungen wirklich einzigartig sind, und das ist seltener, als Teams glauben. Die ehrliche Kontrollfrage: „Was genau an unserem Bedarf kann kein existierendes Tool abdecken?” — wenn die Antwort eine Konfigurationsfrage ist, ist sie kein Build-Argument.

2. Was kostet es über drei bis fünf Jahre — vollständig? Für jede Option dieselbe Rechnung: Lizenz/Subscription + Integrationsaufwand + Betriebsaufwand in Personenzeit + Upgrade-/Wartungsaufwand + Wissensaufbau. Bei Buy gehört die erwartbare Preisentwicklung dazu, bei Adopt der realistische Betriebsanteil (nicht „läuft halt”), bei Build die Weiterentwicklung. Die Zahlen sind Schätzungen — aber allein das Aufschreiben verschiebt viele Bauchentscheidungen.

3. Passt es zum Team? Eine Rego-basierte Policy-Engine in einem Team ohne Rego-Erfahrung, ein TypeScript-lastiges Portal in einem reinen Go-Team — technisch lösbar, praktisch ein Dauerwiderstand. Vorhandene Skills sind ein legitimes, oft entscheidendes Kriterium.

4. Wie kommst du wieder raus? Die Exit-Frage vor dem Einstieg stellen: Liegen die Daten/Konfigurationen in offenen Formaten? Gibt es einen Migrationspfad zu Alternativen? Eine Buy-Entscheidung mit klarem Exit ist risikoärmer als eine Adopt-Entscheidung, deren Eigenanpassungen ein faktisches Lock-in bilden — Lock-in ist keine Frage von kommerziell oder nicht, sondern von Austauschbarkeit.

In der Praxis sind reife Plattform-Stacks fast immer Mischungen: Commodity-Bausteine adoptiert oder gekauft, dünne Eigenbau-Schicht nur dort, wo die Organisation wirklich speziell ist — typischerweise in der Integration der Bausteine und der eigenen Platform API, nicht in den Bausteinen selbst.

Entscheiden heißt auch: Zeitpunkt und Reversibilität

Zwei Verfeinerungen, die im Interview den Unterschied machen:

Reversibilität bestimmt die Sorgfalt (das Prinzip aus Lektion 6): Ein Dashboard-Tool zu wechseln ist billig — schnell entscheiden, notfalls korrigieren. Eine Workflow-Engine, in der hunderte Teams ihre Pipelines definiert haben, ist faktisch irreversibel — hier lohnen Proof of Concepts mit echten Workloads, Referenz-Gespräche und ein dokumentierter Vergleich.

Default-Pfad mit Wechsel-Triggern: Statt der Illusion einer endgültigen Entscheidung definierst du Bedingungen, unter denen sie revidiert wird — „Wir adoptieren X; wenn der Betriebsaufwand dauerhaft über einer halben Stelle liegt oder das Projekt zwei Releases in Folge verschiebt, evaluieren wir Buy-Alternative Y.” Das nimmt Entscheidungsdruck und macht die Annahmen überprüfbar.

Praxis: eine Portal-Entscheidung durchspielen

Szenario: 35 Entwicklungsteams, das Plattform-Team hat 6 Personen (stark in Go und Kubernetes, wenig Frontend-Erfahrung). Gesucht: Developer Portal mit Service Catalog und Scaffolding. Kandidaten: (A) Open-Source-Portal-Framework selbst betreiben und anpassen, (B) Portal-SaaS kaufen, (C) schlankes internes Portal selbst bauen.

1. Kriterienmatrix: Lege eine Tabelle an — Zeilen: Differenzierung, 3-Jahres-Kosten (Schätzung in Personenmonaten + Lizenz), Team-Fit, Exit-Aufwand, Time-to-Value. Spalten: A, B, C. Fülle jede Zelle mit ein, zwei Stichworten; markiere pro Zeile den Gewinner.
2. Empfehlung schreiben: Fünf bis acht Sätze an deine Engineering-Leitung: Empfehlung, die zwei stärksten Gründe, der größte Nachteil deiner Wahl (ehrlich!), und ein Wechsel-Trigger.
3. Angriff aushalten: Formuliere die härteste Gegenfrage, die ein Vertreter der unterlegenen Optionen stellen würde — und deine Antwort in zwei Sätzen.

Es gibt kein „richtiges” Ergebnis — bewertet wird (auch im echten Interview) die Qualität der Abwägung. Mit Team-Fit „wenig Frontend” und 6 Personen ist Option C allerdings schwer zu verteidigen.

Typische Stolperfallen

Open Source mit kostenlos verwechseln. Die Lizenz kostet nichts, der Betrieb eine halbe bis ganze Stelle — wer das nicht einpreist, vergleicht Äpfel mit Rechnungen.

Not-invented-here und sein Gegenteil. Teams, die alles selbst bauen wollen, und Organisationen, die reflexhaft kaufen, machen denselben Fehler: Sie entscheiden nach Identität statt nach Kriterien.

Die Demo entscheiden lassen. Vendor-Demos zeigen den Happy Path mit vorbereiteten Daten. Belastbar ist nur ein PoC mit den eigenen, hässlichen Realfällen — alten Repos, Sonderlocken, echten Berechtigungsstrukturen.

Entscheidung ohne Dokumentation. In zwei Jahren fragt jemand „Warum haben wir eigentlich X?” — und niemand weiß es mehr. Die Antwort auf dieses Problem hat eine eigene Lektion verdient: die nächste.

Interview-Vorbereitung

Auf „Wie entscheidest du Build vs. Buy vs. Adopt?” antwortest du am stärksten so: Erst die Differenzierungsfrage (Commodity → nicht bauen) → vollständige Kosten über Jahre (inklusive Betrieb und Wartung, nicht nur Lizenz/Initialaufwand) → Team-Fit und Exit-Strategie → Reversibilität bestimmt die Sorgfalt, plus Wechsel-Trigger statt Endgültigkeits-Illusion. Idealerweise mit einem konkreten Beispiel aus deiner Erfahrung — auch ein kleines („wir haben das Eigenbau-Skript durch Tool X ersetzt, weil…”) schlägt Theorie.

Rechne mit diesen Follow-ups:

• „Wann ist Build gerechtfertigt?” — Wenn der Bedarf echte Differenzierung ist und kein Tool ihn abdeckt; typischerweise die dünne Integrationsschicht und die eigene Platform API, nicht die Commodity-Bausteine.
• „Was ist das größte Risiko bei Adopt?” — Der unterschätzte Dauerbetrieb plus Projektrisiko (Governance, Sponsor-Abhängigkeit); Gegenmittel: Betriebsaufwand realistisch budgetieren und Projekt-Gesundheit beobachten.
• „Wie gehst du mit Vendor-Lock-in um?” — Lock-in als Austauschbarkeitsfrage behandeln: offene Formate, Exit-Pfad vor Vertragsschluss prüfen, Wechselkosten bewusst gegen den Nutzen abwägen — etwas Lock-in ist oft der faire Preis für Time-to-Value.
• „Wie verhinderst du, dass solche Entscheidungen nach Bauchgefühl fallen?” — Leichtgewichtiger fester Prozess: Kriterienmatrix, PoC bei schwerer Reversibilität, dokumentierte Entscheidung mit Begründung — Stichwort ADR.

Zusammenfassung

Build, Buy und Adopt unterscheiden sich weniger im sichtbaren Preis als in den unsichtbaren Posten: Adopt heißt betreiben, Buy heißt Lock-in und Preisrisiko managen, Build heißt dauerhaft weiterentwickeln. Tragfähige Entscheidungen beantworten vier Fragen — Differenzierung oder Commodity, vollständige Mehrjahreskosten, Team-Fit, Exit-Pfad — und kalibrieren die Sorgfalt an der Reversibilität. Reife Plattformen mischen: Commodity adoptiert oder gekauft, Eigenbau nur in der dünnen Schicht, die die Organisation wirklich unterscheidet.

Damit so eine Abwägung in zwei Jahren noch nachvollziehbar ist, braucht sie ein Format. Das liefert die nächste Lektion: Architecture Decision Records.