Die Reversibilitätskurve: Warum Build vs. Buy mit der Zeit schwieriger wird

Laut der Exclaimer-Studie Build vs. Buy Report [ENG] werden 71 % aller intern gebauten IT-Tools irgendwann aufgegeben. Der größere Aufwand entsteht aber davor: jahrelange Wartungsarbeit, die sich still ansammelt, solange das Tool noch im Einsatz ist.

Interne Eigenentwicklungen sterben selten mit einem lauten Knall. Der Wartungsaufwand wächst über Monate hinweg, und an einem Montagmorgen stellt ein Datenbankteam fest, dass es einen halben Arbeitstag damit verbringt, Reports für ein Abrechnungssystem zu flicken, das vor drei Jahren hätte abgelöst werden müssen. Bis dahin sitzt das Tool so tief in den Prozessen, dass es sich nur noch mit einem eigenen Projekt herausziehen lässt.

Genau dieses Muster zog sich als roter Faden durch das Webinar „Why build vs buy decisions get harder over time“, ein Gespräch zwischen Jeff Grettler, Head Brand Ambassador und Content Creator bei Spiceworks Ziff Davis, und Karl Bagci, Director of IT and Information Security bei Exclaimer. Karls Argument war simpel: Build vs. Buy ist eine Zeitfrage, und das Fenster, in dem sich die Entscheidung sauber treffen lässt, bleibt nicht lange offen. Hier sind die wichtigsten Erkenntnisse.

Die Reversibilitätskurve

Frühe Build-Entscheidungen lassen sich günstig revidieren. Die Kosten für einen Kurswechsel steigen schnell, sobald ein Tool Abhängigkeiten aufbaut und sich im Tagesgeschäft festsetzt.

Karl bezeichnete diesen Effekt als die Reversibilitätskurve. Ein 2013 selbst gebauter Monitoring-Stack sieht am ersten Tag aus wie ein schneller Erfolg. Drei Jahre später sitzt er im Zentrum der Infrastruktur, abhängig von individuellen Integrationen und von der einen Person, die noch weiß, wie die Cronjobs zusammenhängen. Das Ablösen ist dann kein Projekt mehr, sondern eine Migration.

Karl schilderte ein Beispiel aus einer früheren Position. Sein Datenbank-Team verbrachte jeden Tag einen halben Arbeitstag damit, defekte Reports aus einem selbst gebauten Abrechnungssystem zu reparieren. Das Tool zu entfernen, hätte eine erhebliche Investition an Zeit und Geld bedeutet. Es zu behalten, kostete dauerhaft etwas weniger, aber eben dauerhaft. Als die Kosten der Eigenentwicklung offensichtlich wurden, waren die Kosten für ihre Ablösung längst nicht mehr tragbar.

Jeff ergänzte die Sysadmin-Variante desselben Problems: Es gibt immer den einen Server im Rack, den niemand anfasst, weil niemand mehr weiß, was davon abhängt. Bis das Team sich einig ist, dass er weg muss, kostet die Ablösung mehr, als sie je gekostet hätte.

Die versteckten Kosten sind Zeit

Eine Lizenzgebühr ist die einfache Zahl zum Vergleichen. Die schwierigere Zahl sind die Wartungsstunden, die eine interne Eigenentwicklung verschlingt, sobald sie läuft, und das, was diese Stunden stattdessen hätten leisten können.

Die Studie von Exclaimer, basierend auf einer Befragung von über 2.000 IT- und Security-Verantwortlichen, deckt sich mit dieser Erfahrung. 63 % der Befragten verbringen zwischen 10 und 50 Stunden im Monat mit der Wartung selbst gebauter Tools. Zwei Drittel geben zwischen 20.000 und 100.000 US-Dollar pro Jahr allein für die Wartung aus. Nur 8 % aller internen Eigenentwicklungen werden pünktlich fertig. Keine dieser Zahlen taucht üblicherweise im ursprünglichen Business Case auf.

Das größere Risiko sind die Menschen. Karl nennt Verantwortlichkeit und Dokumentation die am stärksten unterschätzten Aspekte jeder Build-Entscheidung. Ein 2022 von einer Person gebautes Tool läuft 2026 vielleicht noch tadellos, bis diese Person das Unternehmen verlässt und niemand sonst die Codebasis kennt. Verantwortlichkeit von Beginn an festzulegen, ist wichtiger, als die meisten Teams ihm zugestehen. Wenn niemand namentlich benannt ist, um das Tool zu warten oder den Anruf am Sonntagmorgen um 2 Uhr entgegenzunehmen, wenn etwas zusammenbricht, ist das Tool bereits ein zukünftiges Problem.

Vibe Coding macht die Kurve steiler

KI-gestützte Entwicklung hat die Einstiegshürde fürs Bauen gesenkt. Sie hat auch die Lücke zwischen denen, die bauen können, und denen, die beurteilen können, was „gut“ eigentlich heißt, weiter aufgerissen.

Vibe Coding und Low-Code-Plattformen haben die Build-Option zugänglicher gemacht als je zuvor, und nicht nur für Ingenieurinnen und Ingenieure. Das Problem dabei, so Karl: Die Leute, die bauen, sind nicht immer die Leute, die über grundlegende Sicherheitshygiene nachdenken. Basisfragen, wo die Daten liegen oder was passiert, wenn ein Tool auf ein System mit sensiblen Kundendaten zugreift, schaffen es nicht zuverlässig in den Entwicklungsprozess.

Karls Team hat damit begonnen, Vibe-Coding-Apps denselben Software Development Life Cycle durchlaufen zu lassen wie produktiven Code, inklusive Review und Code-Scanning, bevor sie produktiv gehen. Das Ziel: den Geschwindigkeitsvorteil erhalten, das Langzeitrisiko begrenzen. Aus einem aktuellen Gespräch in einer CISO-Runde nahm Karl dasselbe Bild mit. Eine selbstbewusste Antwort auf die Frage, wie sich das sauber regeln lässt, hat bislang niemand.

Den Ausstieg sauber argumentieren

Die meisten Build-vs.-Buy-Diskussionen werden auf der Übersetzungsebene gewonnen oder verloren, nicht auf der technischen. Die Kosten der Untätigkeit zu beziffern, ist meist der fehlende Teil.

Einen CFO interessiert keine technische Aufschlüsselung, warum ein Legacy-System fragil ist. Ihn interessiert, was mit der Bilanz passiert, wenn es ausfällt, und wie das finanzielle Risiko in den nächsten drei bis fünf Jahren aussieht, wenn alles bleibt, wie es ist. Die am häufigsten übersehene Hälfte dieses Gesprächs sind laut Karl die Kosten der Untätigkeit. IT-Teams sind gut darin, das Risiko einer Veränderung zu beziffern. Sie sind weniger geübt darin, das Risiko des Nichtstuns zu beziffern. Beide Zahlen gehören auf den Tisch.

Karl schloss mit einem Satz, der sich gut in die Planung für 2026 mitnehmen lässt: Halten Sie sich Ihre Optionen so lange offen wie möglich. Das bedeutet nicht, im Zweifel zu kaufen. Es bedeutet, jede Eigenentwicklung als Entscheidung zu behandeln, die Sie noch einmal überprüfen müssen, und den Ausstieg zu planen, bevor Sie ihn brauchen. Ein halb gebautes Tool aufzugeben, kann die richtige Antwort auf bessere Informationen sein.

Komfort, so Karl, wird mit zunehmender Karriere wertvoller. Dasselbe gilt für IT-Funktionen, je reifer sie werden.

Was das für das E-Mail-Signatur-Management bedeutet

Dasselbe Muster zeigt sich in alltäglichen IT-Funktionen, einschließlich des E-Mail-Signatur-Managements. Was als schnelles PowerShell-Skript beginnt, wird zur fragilen Abhängigkeit, die niemand mehr verantworten will.

Exclaimer ist der weltweit führende Anbieter für die zentrale Verwaltung von E-Mail-Signaturen in Microsoft 365 und Google Workspace und wird von über 75.000 Unternehmen weltweit eingesetzt, darunter Sony, Bank of America, die BBC und die Academy Awards. Mit über 20 Jahren Erfahrung nimmt die Cloud-Lösung von Exclaimer der IT die Administration aus den Händen. E-Mail-Signaturen und Meeting Branding werden zentral über alle Nutzenden und Geräte hinweg verwaltet, Richtlinien automatisch angewendet und in Echtzeit aktualisiert.

Für IT-Teams, die bereits auf der Build-Seite der Kurve stehen, ist die praktische Frage eine Frage des Zeitpunkts. Je weiter eine intern gebaute Lösung treibt, desto höher werden die Kosten ihrer Ablösung im Verhältnis zu den Kosten ihrer Wartung.

Das Webinar on-demand ansehen

Das vollständige Gespräch behandelt die Reversibilitätskurve in der Praxis und beleuchtet, wie KI die Build-vs.-Buy-Entscheidung neu prägt.

Sehen Sie sich das On-Demand-Webinar [ENG] an, um die komplette Session zu erleben, inklusive Karls Argumentation, warum sich die meisten Build-Entscheidungen günstig revidieren lassen, wenn man früh handelt, und was es kostet zu warten.