Bevor du deine eigene interne Plattform aufbaust, schau dir diese Zahlen an

„Wir entwickeln es einfach selbst“ wird meist mit Zuversicht und einer groben Schätzung der benötigten Mitarbeiterzahl gesagt. Sechs Monate später ist das Team, das eigentlich zwei Sprints dafür aufwenden sollte, immer noch dabei, die Plattform zu warten – und das schon seit einem Jahr –, und die Plattform, die eigentlich Entwicklungszeit sparen sollte, ist zu einem der Dinge geworden, für die Entwicklungszeit aufgewendet wird.

Selbst zu entwickeln ist nicht automatisch die falsche Entscheidung. Manchmal ist es die richtige. Was jedoch meistens fehlt, ist die Zahl, die Teams vor ihrer Entscheidung übersehen – jene, die erst sichtbar wird, wenn die Entscheidung bereits feststeht.

Die Schätzung für die Entwicklung berücksichtigt fast nie die Wartung

Das Wichtigste zum Mitnehmen: Die anfänglichen Entwicklungskosten machen nur den kleinsten Teil der Gesamtkosten aus. Die Rechnung, die immer wieder ins Haus flattert, ist die, die niemand im Budget eingeplant hat.

Ein Entwicklungsvorschlag beziffert in der Regel die Kosten für die Einrichtung der Plattform: Provisioning, CI/CD-Einrichtung, Umgebungsvorlagen, Zugriffskontrollen. Was darin selten berücksichtigt wird, ist das, was nach dem Start passiert. Jemand muss Patches installieren, wenn für eine Abhängigkeit eine Sicherheitswarnung vorliegt. Jemand muss die Plattform erweitern, wenn der Workflow eines neuen Teams nicht zum ursprünglichen Design passt. Jemand muss die Person sein, die sich gut genug auskennt, um um 23 Uhr Fehler zu beheben, wenn etwas nicht mehr funktioniert.

Dieser Jemand ist meist ein Senior-Ingenieur, und die Stunden, die er damit verbringt, die interne Plattform am Laufen zu halten, sind Stunden, die er nicht für das Produkt aufwendet, das das Unternehmen tatsächlich verkauft. Die Anzahl der Sprints im ursprünglichen Vorschlag war nie die Zahl, auf die es ankam. Die Zahl, auf die es ankommt, ist, wie viele Senior-Ingenieur-Stunden pro Monat dies auf unbestimmte Zeit erfordert – und was diese Stunden stattdessen sonst noch hervorbringen könnten.

Die Kosten für den Kauf sind sichtbar. Die Kosten für die Eigenentwicklung sind einfach schwerer zu erkennen

Das Wichtigste zum Mitnehmen: Beide Optionen kosten Geld. Die eine taucht als Einzelposten auf, den jemand genehmigen muss. Die andere verteilt sich auf Menschen, Zeit und Chancen – und genau deshalb wird sie so leicht unterschätzt.

Der Drang, selbst zu entwickeln, entspringt oft einer berechtigten Sorge: Die ressourcenbasierte Preisgestaltung eines Anbieters ist ein Posten, den jemand genehmigen muss, während interne Entwicklungszeit sich „kostenlos“ anfühlt, weil sie ohnehin auf der Gehaltsliste steht. Diese „kostenlose“ Zeit wird bereits bezahlt – in Form von Gehalt –, und jede Stunde, die für die Wartung interner Plattform-Tools aufgewendet wird, ist eine Stunde, die nicht für das verwendet wird, was die Einstellung dieses Entwicklers ursprünglich gerechtfertigt hat.

Durch den Kauf tauscht man variable, versteckte Kosten gegen feste, sichtbare ein. Dieser Tausch lohnt sich immer dann, wenn die Plattformarbeit selbst für das Unternehmen keinen Wettbewerbsvorteil darstellt – und für die meisten Unternehmen ist das bei der Bereitstellung und Standardisierung von Umgebungen einfach nicht der Fall.

Die Hybrid-Option, die die meisten Teams überspringen

Das Wichtigste auf einen Blick: „Selbst entwickeln“ und „kaufen“ sind nicht die einzigen beiden Optionen, die zur Auswahl stehen. Die standardisierte Basis zu kaufen und nur die dünne Schicht selbst zu entwickeln, die wirklich spezifisch für dein Unternehmen ist, ist oft besser, als voll auf eines der beiden Extreme zu setzen.

Die „Build-versus-Buy“-Perspektive betrachtet dies als Entweder-oder-Entscheidung, doch die meisten Bereitstellungsmodelle bündeln zwei sehr unterschiedliche Arten von Arbeit: die „Grundinfrastruktur“, die jedes Unternehmen braucht (Bereitstellung, Konsistenz der Umgebungen, Zugriffskontrolle, Rollback), und die wenigen Dinge, die wirklich spezifisch dafür sind, wie genau dieses bestimmte Unternehmen Software ausliefert. Die Grundinfrastruktur lohnt sich selten selbst zu entwickeln. Der spezifische Teil manchmal schon.

Bei einem hybriden Ansatz kauft man die standardisierte Grundlage von einem Anbieter und reserviert die Entwicklungszeit des Teams für die darüberliegende Schicht, die das Unternehmen tatsächlich von anderen abhebt – etwa ein maßgeschneidertes Bereitstellungs-Gate, das an einen firmeneigenen Compliance-Prozess gekoppelt ist, oder ein internes Tool, das sich in einen Workflow einbindet, den kein Anbieter unterstützen muss. Das ist ein viel kleinerer Entwicklungsaufwand als eine komplette interne Plattform und verursacht deutlich geringere Wartungskosten.

Die eigentliche Frage ist, welche Teile dessen, was du entwickeln willst, tatsächlich einzigartig für dein Unternehmen sind – und welche die gleichen Probleme bei der Bereitstellung und Konsistenz betreffen, die jede andere Entwicklungsabteilung bereits gelöst hat – und nicht, ob du etwas selbst entwickelst oder kaufst.

Die Zahlen, die du berechnen solltest, bevor du dich entscheidest

Das Wichtigste auf einen Blick: Drei Zahlen verwandeln die Debatte „Selbst entwickeln oder kaufen“ in eine Kalkulation.

Bevor du dich für eine der beiden Optionen entscheidest, lohnt es sich, drei Fragen mit konkreten Zahlen zu untermauern:

1. Was würde die Eigenentwicklung tatsächlich kosten, einschließlich des zweiten Jahres?
   Nicht nur die anfängliche Sprint-Schätzung, sondern eine realistische Aufstellung der laufenden Wartungskosten: Patches, Upgrades, die Einarbeitung neuer Teammitglieder in ein maßgeschneidertes System und die Bewältigung der Sonderfälle, die auftreten, sobald echte Teams das System nutzen.
2. Was wäre es wert, diese Entwicklungszeit stattdessen anderweitig einzusetzen?
   Wenn dieselben erfahrenen Entwickler diese Zeit für die Produkt-Roadmap aufwenden würden, was wäre das wert – entweder in Bezug auf die Umsatzauswirkungen oder die Kosten, die dadurch entstehen, dass keine zusätzliche Person dafür eingestellt werden muss?
3. Was kostet es eigentlich, „gut genug“ zu kaufen? Nicht nur den Listenpreis, sondern im Vergleich zu den Wartungskosten aus Frage eins über denselben Zeithorizont. Eine Entwicklung, die über ein Quartal hinweg günstiger erscheint, sieht über zwei Jahre oft schlechter aus.

Um die Zahlen besser zu veranschaulichen, nimm ein Beispiel, kein verifiziertes Benchmark-Ergebnis: drei erfahrene Entwickler, von denen jeder ein Fünftel seiner Zeit mit der Wartung der Version verbringt – ein realistisches Verhältnis für eine mittelgroße Plattform. Bei Gesamtkosten von etwa 180.000 Dollar pro Jahr und Entwickler entspricht dieses Fünftel ihrer Zeit etwa 108.000 Dollar pro Jahr – jedes Jahr –, noch bevor man berücksichtigt, was diese Entwickler stattdessen nicht entwickeln konnten.

Verglichen mit der ressourcenbasierten Preisgestaltung eines Anbieters für die entsprechende standardisierte Basis sieht dieser Vergleich meist ganz anders aus als die einmalige Sprint-Schätzung, durch die der Build ursprünglich genehmigt wurde.

Führe die echte Version dieser Rechnung mit deinen eigenen Zahlen durch, parallel zu den beiden anderen Fragen, und die Debatte löst sich meist von selbst. Es geht nicht mehr um Prinzipien, sondern wird zu einer Tabellenkalkulation.

Egal, wohin die Zahlen weisen – ob selbst entwickeln, kaufen oder eine Mischform –, die standardisierte Basis darunter ist dieselbe: konsistent bereitgestellte Umgebungen, meist der Teil des Bereitstellungsmodells, den es sich am meisten lohnt zu kaufen statt selbst zu entwickeln, sei es bei Upsun oder anderswo.

Weiterführende Lektüre: 7 Schwachstellen in deinem Bereitstellungsmodell, die du vor deinem nächsten Audit oder Ausfall beheben solltest

Möchtest du einen klaren Überblick darüber, was der Aufbau einer eigenen Plattform dein Team basierend auf deiner Konfiguration wirklich kosten würde? Buche eine Überprüfung zur Plattformstandardisierung.

Häufig gestellte Fragen (FAQ)

Ist es jemals die richtige Entscheidung, eine interne Plattform selbst zu entwickeln, anstatt sie zu kaufen?
Ja, wenn die Plattformarbeit selbst für das Unternehmen einen echten Mehrwert darstellt oder wenn die Anforderungen so ungewöhnlich sind, dass keine Anbieterlösung ohne umfangreiche Anpassungen passt. Bei den meisten Standard-Workflows zur Bereitstellung und Auslieferung von Umgebungen ist dies nicht der Fall, weshalb sich die Wartungskosten selten amortisieren.

Was ist der am häufigsten unterschätzte Kostenfaktor bei einer Entscheidung für die Eigenentwicklung?
Die laufende Wartung. Die meisten Kostenvoranschläge für die Eigenentwicklung berücksichtigen zwar den anfänglichen Projektzeitplan, nicht aber die wiederkehrenden Entwicklungsstunden, die nötig sind, um die Plattform auf dem neuesten Stand zu halten, zu erweitern und an sich ändernde Team-Anforderungen anzupassen.

Wie vergleicht man die Kosten für eine Eigenentwicklung fair mit den Anschaffungskosten?
Vergleiche sie über denselben Zeithorizont, typischerweise zwei bis drei Jahre, und berücksichtige dabei die Entwicklungszeitkosten für die Wartung der Eigenentwicklung, nicht nur die anfänglichen Projektkosten. Der Preis eines Anbieters ist von vornherein sichtbar; die wahren Kosten einer Eigenentwicklung werden erst im Laufe der Zeit sichtbar.

Was sollte ein Team tun, bevor es sich für eine der beiden Optionen entscheidet?
Setzt die Kostenvoranschläge für die Eigenentwicklung mit konkreten Zahlen in Beziehung, einschließlich der Wartungskosten im zweiten und dritten Jahr, und vergleicht diese Gesamtsumme mit den Kosten, die der Kauf über denselben Zeitraum verursachen würde. Der Vergleich bringt in der Regel von selbst die Entscheidung.