Zum Inhalt springen

Wissensbasis

Build-or-Buy-Framework

Build oder Buy entscheidet ihr entlang von vier Dimensionen: funktionale, technische und operative Komplexität sowie einzigartiger Geschäftswert. Danach zählt ihr die Kosten auf fünf Stufen, von Technologie und Personal bis zu verlorenem Geschäft und verpasster Chance. Baut selbst, was euer Geschäft unterscheidet und was euer Team versteht und betreiben kann.

Verfasst von

Aktualisiert:

Software Engineering 5

Unsere Position. KI lässt die Kosten fürs Bauen einbrechen, deshalb hat sich die Rechnung zwischen Build und Buy verschoben. Investiert in die Weiterbildung eures Teams und in euer eigenes internes Tooling, statt geschlossene Plattformen von Anbietern zu mieten. Gekaufte Standardlösungen bringen Tempo auf Zeit, selbst aufgebaute Fähigkeiten einen dauerhaften Vorteil (Build capability (öffnet in einem neuen Tab)).

Das folgende Framework gibt der Entscheidung trotzdem ihre Struktur. Es stammt samt beiden Fallstudien aus Buy or Build? (öffnet in einem neuen Tab), erschienen am 18. April 2020. Wie sich die Frage stellt, wenn Agenten bauen, beschreibt Build versus Buy.

Was sollte eine Build-or-Buy-Entscheidung bewerten?

Jede Build-or-Buy-Entscheidung bewertet ihr entlang von vier Dimensionen. Lasst ihr eine davon aus, entscheidet das Bauchgefühl statt einer strukturierten Analyse.

1. Funktionale Komplexität

Ob ihr die gesamte Funktionalität spezifizieren könnt, gehört zu den wichtigsten Faktoren der Entscheidung. Die Hauptfunktion kennt ihr oft, bei einer Monitoring-Lösung etwa Metriken in einem Graphen anzeigen. Der Teufel steckt aber im Detail. Nehmt euch Zeit, die Randfunktionen zu entdecken. Sonst stürzt ihr euch kopfüber in den Bau von etwas scheinbar Einfachem und bleibt dann stecken.

Wie geht die Monitoring-Lösung etwa mit Server-Churn bei den überwachten Services um? Führt sie bei aktiviertem Auto-Refresh jedes Mal die gesamte Query neu aus?

Technik zum Entdecken: Schaut euch konkurrierende Produkte an, die die Lösung anbieten, und prüft, wie sie sich voneinander abheben. Jedes dieser Unterscheidungsmerkmale ist Funktionalität, die für manche Kund:innen relevant ist. Sie könnte auch für euch relevant sein.

2. Technische Komplexität

Zu wissen, was ihr bauen wollt, ist der Ausgangspunkt. Im nächsten Schritt klärt ihr, ob ihr diese Funktionalität auch bauen könnt. Nicht selten sind funktional komplexe Produkte technisch nicht komplex, und umgekehrt.

  • Funktionale Komplexität entsteht aus der Unsicherheit, das gewünschte Verhalten so zu spezifizieren, dass es nachweislich leicht zu programmieren ist.
  • Technische Komplexität entsteht aus der Frage, ob ihr die funktionalen Anforderungen wiederholbar und zuverlässig erfüllen könnt. Interaktives Information Retrieval etwa bleibt trotz jahrelanger Forschung und Entwicklung eine technisch komplexe Domäne. Geschäfts- und Skalierungsanforderungen wachsen schneller als jede Vereinfachung.

Dieses Kriterium gehört zu den leichteren. Versteht ihr die funktionale Komplexität gut genug, wisst ihr auch, ob ihr die Skills für den Eigenbau habt. Oder ob ihr sie durch Einstellungen aufbauen könnt.

3. Operative Komplexität

Was leicht zu bauen ist, kann sich im Betrieb als tückisch schwer erweisen. Besonders schwer ist es, etwas unter Last zuverlässig und mit vorhersagbarer Performance am Laufen zu halten.

Wer schon Rabattaktionen begleitet hat, kennt den Schmerz, ob bei Buchverlagen, Game Engines oder E-Commerce-Plattformen. F/OSS-Technologie läuft im Kleinen wunderbar und fliegt dann unter hoher Last spektakulär auseinander. Das passiert genau dann, wenn das Geschäft am dringendsten darauf angewiesen ist.

Warnsignal: Gibt es für ein Produkt F/OSS-Angebote in Hülle und Fülle und trotzdem hochprofitable “enterprise”-Angebote? Dann deutet das stark auf operative Komplexität hin.

Die Black-Box-Regel: Wollt ihr eine Technologie als Black Box behandeln, setzt keine F/OSS ein, die ihr selbst betreibt. Betreibt ihr etwas selbst, habt ihr es am besten selbst gebaut. Oder ihr könnt die Offenheit seines Quellcodes nutzen und versteht genau, wie es unter der Haube funktioniert. Alternativ erschließt ihr sein Verhalten empirisch: Ihr belastet es über eure absehbaren Anforderungen hinaus und klärt, wie ihr mit seinen Ausfällen umgeht. Beide Wege sind teuer, das Verstehen über den Code wie über das beobachtete Verhalten.

4. Einzigartiger Geschäftswert

Das letzte Kriterium ist keineswegs das unwichtigste: Wie stark hebt die Komponente, die ihr bewertet, euer Geschäft von anderen ab?

Dieser Blick auf das Unterscheidungsmerkmal ist extrem wichtig. Oft heißt es, man solle etwas selbst bauen, weil es geschäftskritisch ist. Nun, das Internet ist auch geschäftskritisch. Trotzdem baut so gut wie niemand sein eigenes Telekommunikationsnetz, oder?

Die Folge fürs Staffing: Baut ihr etwas selbst, das euer Geschäft nicht unterscheidet, hat das eine sehr ernste Folge. Es fehlt die langfristige Investition in die Komponente. Besetzt das Unternehmen ein Team, gibt es immer mehr Leute dorthin, wo es einen klaren, greifbaren Geschäftsnutzen sieht. Je weniger eine Komponente zur Differenzierung beiträgt, desto weniger Aufmerksamkeit bekommt sie beim Staffing.

Bald merkt ihr: Die Komponente war beim Bau Cutting Edge und ist ein paar Jahre später ein Dinosaurier. Der Stand der Technik ist inzwischen viel weiter und womöglich sogar kostengünstiger geworden.

Wie zählt ihr die vollen Kosten?

Ein Mini-Spiel als Rückblick: Wie reif entscheidet ihr bei Kostenvergleichen? Die meisten Teams hören bei Stufe 1 oder 2 auf. Die eigentliche Erkenntnis kommt auf den Stufen 3 bis 5.

Stufe 1: Technologiekosten

Ihr vergleicht die Kosten für Server und andere Betriebskomponenten und seht, wie viel ihr sparen könntet.

Stufe 2: Personalkosten

Ihr rechnet die CTC (Cost to Company) der Entwickler:innen dazu, die die Komponente bauen und betreiben.

Stufe 3: Kosten der Geschäftsentwicklung

Hier wird es knifflig. Angenommen, ihr steckt das Budget aus Stufe 2, also eure fähigsten Engineers, in direkten Geschäftswert. Wie viel zusätzlichen Umsatz bringt das? Und zieht ihr Engineers ab, die gerade direkten Geschäftswert bauen, wie viel Umsatz verliert ihr? Für ein schnell wachsendes Startup, das seinen Produktplan noch umsetzt, können diese Kosten sehr hoch sein.

Stufe 4: Kosten durch verlorenes Geschäft

Noch kniffliger als Stufe 3. Hier vergleicht ihr die finanziellen Auswirkungen von SLAs und Quality of Service:

  • Auswirkung auf den Umsatz pro Minute, wenn die Komponente ausfällt
  • Auswirkung auf den Umsatz, wenn Performance oder Zuverlässigkeit der Komponente nachlassen
  • Umsatzverlust, weil schlechte Performance die Produktivität von Engineering und Business senkt

Stufe 5: Kosten verpasster Geschäftschancen

Der spannendste Aspekt einer Build-or-Buy-Entscheidung. Kurz gesagt erfasst diese Stufe, wie fehlende Investition (Build) oder fehlende Kontrolle (Buy) die Weiterentwicklung des betrachteten Produkts beeinflusst.

Sie hängt eng am Faktor Differenzierung:

  • Selbst gebaut, wenig differenzierend: Wahrscheinlich ist das Team künftig unterbesetzt. Die Kosten auf Stufe 4 wachsen, während der Rest der Welt samt eurer Konkurrenz an Fähigkeiten zulegt.
  • Selbst gebaut, stark differenzierend: Die Differenzierung kann künftig so weit wachsen, dass sie zu einer direkten Umsatzquelle wird.

Wie wirkt das Framework in der Praxis?

Fallstudie 1: Chat-Server, Build

Bei Tokopedia musste das Team Peer-to-Peer- und Gruppenchat bauen. Erfahrung mit Lösungen von Drittanbietern hatte es bereits als Referenz.

Funktionale Komplexität: Chat-Funktionalität ist gut verstanden. Das Team konnte die meisten zentralen und peripheren funktionalen Anforderungen klar festlegen. Abgeglichen hat es sie mit dem Kern-Featureset der Drittanbieterlösungen.

Technische Komplexität: Chat-Server galten traditionell als berüchtigt kompliziert zu bauen. Die End-to-End-Latenz bei Hunderttausenden gleichzeitigen Verbindungen in vorhersagbaren Grenzen zu halten, ist ein bekanntes Problem (vgl. C10k- oder C10M-Problem).

Den Unterschied machte das Concurrency-Modell von Go. Das select-Statement (öffnet in einem neuen Tab) machte Chat-Server trivial zu bauen, zusammen mit Goroutinen (öffnet in einem neuen Tab) und schnellem Benchmarking. Tokopedia ist ein Go-Shop und hatte Engineers, die daraus eine zuverlässig funktionierende Lösung machen konnten.

Operative Komplexität: Das Team hatte den Chat-Server von Grund auf gebaut und kontrollierte so sein Verhalten und seine Fehlermuster vollständig. Bei Bedarf konnte es bis in die TCP-Implementierung von Go hinabsteigen. Kaum ein Verhalten blieb, das es nicht verstehen oder steuern konnte. Häufige Stresstests ließen Implementierung und Betrieb Hand in Hand wachsen, zu einer wartungsarmen Lösung.

Einzigartiger Geschäftswert: Chat gehört zu den wichtigsten Kontaktpunkten zwischen einem Unternehmen und seinen Kund:innen. Workflows über den Chat bauen, Geschäftsartefakte ins Chat-Protokoll integrieren, das Erlebnis End-to-End steuern: Das hat sehr hohen Geschäftswert. Mit voller Kontrolle über die Lösung konnten Integrationen auf der jeweils besten Ebene passieren. Sie blieben nicht auf Integrationen an der Oberfläche über die API eines Drittanbieters beschränkt.

Kosten: Das Team ging alle fünf Stufen der Kostenbewertung durch. Für einen der Use Cases lagen die Kosten auf Stufe 1 und 2 bei voller Skalierung 10x niedriger.

Urteil: Build. Geringe technische Komplexität dank Go, hohe funktionale Klarheit, volle operative Kontrolle und hoher Wert als Unterscheidungsmerkmal.

Fallstudie 2: Log-Plattform, Buy

Ebenfalls bei Tokopedia brauchte das Team eine skalierbare Plattform zur Log-Aggregation für das ganze Unternehmen. Sie sollte anwendungsspezifische Logs sammeln und zusätzlich anwendungsübergreifende Analysen mit hoher Interaktivität erlauben.

Funktionale Komplexität: Auf den ersten Blick ist Log-Aggregation gut verstanden und im Umfang begrenzt. Frühere Erfahrung und die Analyse von Drittanbieterangeboten zeigten aber wichtige Randfunktionen. Dazu gehören unter anderem Instanz-Churn in einer containerisierten Umgebung, sehr reaktionsschnelle Interaktion sowie Analytics und Alerting auf Log-Daten.

Technische Komplexität: Interaktives Information Retrieval in großem Maßstab ist ein komplexes Problem. Einfache Log-Aggregation mit simplen Filtern war intern machbar. Vollwertige Log-Analytics zu bauen, ist dagegen technisch komplex.

Operative Komplexität: Die einzige Option war, eine F/OSS-Lösung zusammenzustellen und als Black Box zu betreiben. Das ging nicht gut. Eine Log-Plattform zu verstehen, ist extrem teuer, als White Box durch Code-Lesen ebenso wie empirisch durch Stresstests, die Ausfälle zeigen. Niemand wollte, dass die Wartung der Log-Plattform für jemanden zum Vollzeitjob wird. Die Plattform nahm täglich TBs an Log-Daten auf und musste für Lastspitzen bei Rabattaktionen um das 10-Fache skalieren. Ingestion- und Query-Zeiten dabei niedrig genug für “real-time, interactive” Performance zu halten, war nicht machbar.

Einzigartiger Geschäftswert: Log-Aggregation und -Analyse sind geschäftskritisch, aber kein Unterscheidungsmerkmal. Es gab keinen geschäftsspezifischen Use Case, den Standardlösungen nicht abdecken konnten. Die Differenzierung war sehr gering.

Kosten: Die Analyse zeigte, dass eine Inhouse-Lösung auf Stufe 2 bis 5 höhere Kosten verursacht hätte. Diese Kosten hätten jede Ersparnis auf Stufe 1 aufgezehrt, und der Abstand wuchs mit der Skalierung.

Urteil: Buy. Hohe technische und hohe operative Komplexität, geringer Wert als Unterscheidungsmerkmal und ungünstige Kostendynamik bei Skalierung. Das Team entschied sich für eine Drittanbieterlösung (öffnet in einem neuen Tab).

Wann solltet ihr verkaufen, was ihr gebaut habt?

Die meisten Teams hören nach der Build-or-Buy-Entscheidung auf. Dasselbe Framework hilft aber auch bei der Frage, ob ihr verkaufen solltet, was ihr gebaut habt. Dafür kommen zwei Überlegungen hinzu.

Extern relevante Differenzierung

Baut ihr etwas hoch Komplexes selbst, hat das meist einen von zwei Gründen. Es hat für euch hohen Wert als Unterscheidungsmerkmal, oder ihr habt die Ökonomie der Drittanbieterlösungen verändert. Was ihr gebaut habt, ist schwer zu bauen und unterscheidet sich zugleich in wesentlichen Punkten von bestehenden Lösungen.

Euer Geschäft agiert nicht isoliert. Andere finden dieselbe Differenzierung womöglich ebenfalls wertvoll. Dann könntet ihr eure Lösung kommerziell verkaufen oder als F/OSS anbieten.

Vorher müsst ihr aber noch eine Sache prüfen.

Kosten der Multi-Tenancy

Eine Inhouse-Lösung baut ihr für euer Unternehmen und eure Use Cases. Wollt ihr sie extern verkaufen, kommt viel zusätzliche Arbeit hinzu:

  • Euer eigenes Unternehmen als einen Tenant eurer Lösung herauslösen
  • Sicherstellen, dass mehrere Tenants sich nicht in die Quere kommen oder die Geschäftsgeheimnisse der anderen entdecken
  • Kostenberechnung und Nutzungsaudits ergänzen
  • Robustere Sicherheit für Endnutzer:innen umsetzen

Manchmal werden schon die Kosten der Multi-Tenancy zu hoch. Vielleicht war die Lösung gerade deshalb profitabel, weil sie nicht mandantenfähig war. Ein Grund, warum Konzerne Enterprise-Lösungen kaufen: Jede Plattform in einem großen Unternehmen braucht von Natur aus Multi-Tenancy. Dort arbeiten Teams aus verschiedenen Geschäftsbereichen. Sie müssen geteilte Technologie intern verrechnen. Und sie nehmen es nicht auf die leichte Schulter, wenn das Fehlverhalten einer Schwestereinheit sie Zuverlässigkeit kostet.

Die Entscheidung zum Verkauf: Erst wenn die extern relevante Differenzierung hoch ist UND die Kosten der Multi-Tenancy beherrschbar sind, solltet ihr erwägen, ein Produkt aus eurer Lösung zu machen.

Warum gehen Build-or-Buy-Entscheidungen schief?

Verschiedene Märkte neigen unterschiedlich stark zu Buy oder Build. Viele Entscheidungen fallen “emotional”. Funktionale und technische Komplexität halten Teams oft nicht auseinander. Dazu kommen falsche Abwägungen zwischen kurz- und langfristigen Aussichten.

Strukturiert die Analyse mit den vier Dimensionen: funktionale Komplexität, technische Komplexität, operative Komplexität und einzigartiger Geschäftswert. Beziffert sie ehrlich mit den fünf Kostenstufen. Und baut ihr am Ende etwas Großartiges, entscheidet mit dem Verkaufs-Framework, ob die Welt es auch bekommen sollte.

Verwandte Seiten

Quellen

Artikel

  • Buy or Build? (öffnet in einem neuen Tab) - LinkedIn-Artikel, aus dem die vier Bewertungsdimensionen, die fünf Kostenstufen und beide Fallstudien dieser Seite stammen, ein Chat-Server und eine Log-Plattform.

Dokumentation

Posts

  • Build capability (öffnet in einem neuen Tab) - LinkedIn-Post mit dem Argument, dass KI die Kosten des Bauens einbrechen lässt. Teams sollten deshalb in Weiterbildung und internes Tooling investieren statt in gemietete Anbieterplattformen.

Tools und Repositories

  • Scalyr (öffnet in einem neuen Tab) - Produktseite von Scalyrs Log-Management als archivierter Snapshot vom Mai 2020, die Drittanbieterlösung, für die sich die Buy-Fallstudie entschied.